* system gets stuck in a lock during boot
@ 2009-08-13 15:42 Justin P. Mattock
2009-08-18 10:49 ` Frederic Weisbecker
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-13 15:42 UTC (permalink / raw)
To: Linux Kernel Mailing List
I posted already and had no reply,
I cannot boot my system with the latest git
seems to be stuck in some lock:
[ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
[ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
[ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
[ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
[ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
[ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
[ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
[ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
[ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
[ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
[ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
[ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
[ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
[ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
[ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
[ 0.659276] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
[ 0.659519] [<ffffffff81697061>] event_trace_init+0x157/0x1a2
[ 0.659762] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
[ 0.660008] [<ffffffff810091db>] do_one_initcall+0x65/0x14e
[ 0.660251] [<ffffffff81140000>] ? proc_set_super+0x49/0x5d
[ 0.660488] [<ffffffff8167ef53>] kernel_init+0x160/0x1cc
[ 0.660731] [<ffffffff8102801a>] child_rip+0xa/0x20
[ 0.660973] [<ffffffff8167edf3>] ? kernel_init+0x0/0x1cc
[ 0.661220] [<ffffffff81028010>] ? child_rip+0x0/0x20
seems my other machine boots just fine, maybe this is something
with x86_64.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-13 15:42 system gets stuck in a lock during boot Justin P. Mattock
@ 2009-08-18 10:49 ` Frederic Weisbecker
2009-08-18 16:09 ` Steven Rostedt
0 siblings, 1 reply; 62+ messages in thread
From: Frederic Weisbecker @ 2009-08-18 10:49 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: Linux Kernel Mailing List
On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
> I posted already and had no reply,
> I cannot boot my system with the latest git
>
> seems to be stuck in some lock:
>
> [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
> [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
> [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
> [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
> [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
> [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
> [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
> [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
> [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
> [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
> [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
> [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
> [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
> [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
> [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
Ouch...
I've never seen such panic. Could you send me your config, hopefully
I could reproduce it?
Thanks.
> [ 0.659276] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
> [ 0.659519] [<ffffffff81697061>] event_trace_init+0x157/0x1a2
> [ 0.659762] [<ffffffff81696f0a>] ? event_trace_init+0x0/0x1a2
> [ 0.660008] [<ffffffff810091db>] do_one_initcall+0x65/0x14e
> [ 0.660251] [<ffffffff81140000>] ? proc_set_super+0x49/0x5d
> [ 0.660488] [<ffffffff8167ef53>] kernel_init+0x160/0x1cc
> [ 0.660731] [<ffffffff8102801a>] child_rip+0xa/0x20
> [ 0.660973] [<ffffffff8167edf3>] ? kernel_init+0x0/0x1cc
> [ 0.661220] [<ffffffff81028010>] ? child_rip+0x0/0x20
>
>
>
> seems my other machine boots just fine, maybe this is something
> with x86_64.
>
> Justin P. Mattock
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 10:49 ` Frederic Weisbecker
@ 2009-08-18 16:09 ` Steven Rostedt
2009-08-18 16:24 ` Justin Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-08-18 16:09 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: Justin P. Mattock, Linux Kernel Mailing List
On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
> > I posted already and had no reply,
> > I cannot boot my system with the latest git
> >
> > seems to be stuck in some lock:
> >
> > [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
> > [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
> > [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
> > [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
> > [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
> > [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
> > [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
> > [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
> > [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
> > [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
> > [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
> > [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
> > [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
> > [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
> > [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
>
>
>
> Ouch...
>
> I've never seen such panic. Could you send me your config, hopefully
> I could reproduce it?
Send me the config too please.
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 16:09 ` Steven Rostedt
@ 2009-08-18 16:24 ` Justin Mattock
2009-08-18 19:57 ` Steven Rostedt
2009-08-18 23:29 ` Steven Rostedt
0 siblings, 2 replies; 62+ messages in thread
From: Justin Mattock @ 2009-08-18 16:24 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
> On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
>> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
>> > I posted already and had no reply,
>> > I cannot boot my system with the latest git
>> >
>> > seems to be stuck in some lock:
>> >
>> > [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
>> > [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
>> > [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
>> > [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
>> > [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
>> > [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
>> > [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
>> > [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
>> > [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
>> > [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
>> > [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
>> > [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
>> > [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
>> > [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
>> > [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
>>
>>
>>
>> Ouch...
>>
>> I've never seen such panic. Could you send me your config, hopefully
>> I could reproduce it?
>
> Send me the config too please.
>
> -- Steve
>
>
yeah this happens with rc6 but not with rc5.
The system is a linux from scratch build
x86_64 I used these flags for building everything:
CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
-fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
also: I have a macbook(not x86_64) that is running rc6 that seems
to be fine.(I can double check).
attached is .config, dmesg as well.
--
Justin P. Mattock
[-- Attachment #2: config --]
[-- Type: application/octet-stream, Size: 62008 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.31-rc6
# Mon Aug 17 13:47:08 2009
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_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_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
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_HAVE_DYNAMIC_PER_CPU_AREA=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
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_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
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=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y
#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_COUNTERS=y
#
# Performance Counters
#
CONFIG_PERF_COUNTERS=y
CONFIG_EVENT_PROFILE=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
# CONFIG_OPROFILE_IBS is not set
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
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
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 is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# 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 is not set
# 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_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_NEW_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_CPU_DEBUG is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
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_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
#
# Memory hotplug is currently incompatible with Software Suspend
#
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR_ALL=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
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_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
# CONFIG_HT_IRQ is not set
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_IA32_EMULATION is not set
# CONFIG_COMPAT_FOR_U64_ALIGNMENT is not set
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
# CONFIG_IP_PIMSM_V2 is not set
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
CONFIG_TCP_MD5SIG=y
# CONFIG_IPV6 is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
# CONFIG_NETFILTER_XT_TARGET_LED is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
# CONFIG_NETFILTER_XT_MATCH_OSF is not set
CONFIG_IP_VS=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS application helper
#
# CONFIG_IP_VS_FTP is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
# CONFIG_DCB is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
# CONFIG_BT_HCIUART_LL is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
CONFIG_RXKAD=m
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
CONFIG_CFG80211_REG_DEBUG=y
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=y
CONFIG_LIB80211_CRYPT_WEP=y
CONFIG_LIB80211_CRYPT_CCMP=y
CONFIG_LIB80211_CRYPT_TKIP=y
CONFIG_LIB80211_DEBUG=y
CONFIG_MAC80211=y
CONFIG_MAC80211_DEFAULT_PS=y
CONFIG_MAC80211_DEFAULT_PS_VALUE=1
#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG_MENU=y
# CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
# CONFIG_MAC80211_NOINLINE is not set
# CONFIG_MAC80211_VERBOSE_DEBUG is not set
# CONFIG_MAC80211_HT_DEBUG is not set
# CONFIG_MAC80211_TKIP_DEBUG is not set
# CONFIG_MAC80211_IBSS_DEBUG is not set
# CONFIG_MAC80211_VERBOSE_PS_DEBUG is not set
# CONFIG_MAC80211_DEBUG_COUNTERS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD 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 is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=m
# CONFIG_CB710_CORE is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
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 is not set
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 is not set
CONFIG_SCSI_CONSTANTS=y
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 is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_FCOE_FNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
CONFIG_SATA_NV=m
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_PATA_ACPI=m
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
CONFIG_PATA_ATIIXP=m
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=m
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT 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=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=m
# CONFIG_FIREWIRE_NET is not set
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_DV1394=m
# CONFIG_IEEE1394_VERBOSEDEBUG 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 is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH9K is not set
# CONFIG_AR9170_USB is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWLWIFI is not set
CONFIG_HOSTAP=y
# CONFIG_HOSTAP_FIRMWARE is not set
# CONFIG_HOSTAP_PLX is not set
# CONFIG_HOSTAP_PCI is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOL2TP=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_VIRTIO_NET=m
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
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=m
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_LKKBD=m
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
CONFIG_MOUSE_APPLETOUCH=m
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT 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 is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
CONFIG_FIX_EARLYCON_MEM=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=15
# CONFIG_VIRTIO_CONSOLE is not set
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=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_VIA=y
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_NVRAM=m
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=15
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ATMEL is not set
# CONFIG_TCG_INFINEON is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=m
# CONFIG_I2C_ISCH is not set
CONFIG_I2C_PIIX4=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set
#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
CONFIG_I2C_STUB=m
#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
CONFIG_W1_CON=y
#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS2482 is not set
#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2431 is not set
# CONFIG_W1_SLAVE_DS2433 is not set
CONFIG_W1_SLAVE_DS2760=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
CONFIG_POWER_SUPPLY_DEBUG=y
CONFIG_PDA_POWER=m
CONFIG_BATTERY_DS2760=m
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
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 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# 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 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_ARC=m
# CONFIG_FB_ASILIANT is not set
CONFIG_FB_IMSTT=y
CONFIG_FB_VGA16=m
CONFIG_FB_UVESA=m
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=m
# CONFIG_FB_ATY_CT is not set
# CONFIG_FB_ATY_GX is not set
CONFIG_FB_ATY_BACKLIGHT=y
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
CONFIG_FB_VIRTUAL=m
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_BACKLIGHT_MBP_NVIDIA=y
# CONFIG_BACKLIGHT_SAHARA is not set
#
# 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=128
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_FONT_6x11=y
CONFIG_FONT_7x14=y
CONFIG_FONT_PEARL_8x8=y
CONFIG_FONT_ACORN_8x8=y
CONFIG_FONT_MINI_4x6=y
CONFIG_FONT_SUN8x16=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONT_10x18=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_LOGO_LINUX_CLUT224 is not set
CONFIG_SOUND=y
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=y
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
# CONFIG_SND_HDA_INPUT_JACK is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=2
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_SMARTJOYPLUS=y
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_WACOM=m
CONFIG_HID_ZEROPLUS=y
# CONFIG_ZEROPLUS_FF is not set
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 is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# 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_MON is not set
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=y
CONFIG_USB_BERRY_CHARGE=m
CONFIG_USB_LED=y
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set
#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y
#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
# CONFIG_EDAC_AMD64 is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
# CONFIG_EDAC_X38 is not set
# CONFIG_EDAC_I5400 is not set
CONFIG_EDAC_I5000=m
# CONFIG_EDAC_I5100 is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
# CONFIG_UIO_PDRV is not set
# CONFIG_UIO_PDRV_GENIRQ is not set
# CONFIG_UIO_SMX is not set
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
#
# TI VLYNQ
#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
CONFIG_INTEL_MENLOW=m
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# 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 is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
# 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=y
CONFIG_EXT4DEV_COMPAT=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
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 is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set
CONFIG_GENERIC_ACL=y
#
# 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=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EFS_FS=m
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_UPCALL is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
CONFIG_AFS_FS=m
# CONFIG_AFS_DEBUG is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
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 is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_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_FTRACE_SYSCALLS=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# 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 is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
# CONFIG_BUILD_DOCSRC is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
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 is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
#
# 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=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
# CONFIG_SECURITY_SELINUX_DISABLE is not set
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
# CONFIG_CRYPTO_TWOFISH_X86_64 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 is not set
CONFIG_CRYPTO_DEV_HIFN_795X=m
# CONFIG_CRYPTO_DEV_HIFN_795X_RNG is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_KVM_TRACE is not set
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
# CONFIG_VIRTIO_BALLOON is not set
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=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
[-- Attachment #3: dmesg --]
[-- Type: application/octet-stream, Size: 43995 bytes --]
[ 0.000000] Linux version 2.6.31-rc5 (justin@unix) (gcc version 4.5.0 20090730 (experimental) (GCC) ) #1 SMP Mon Aug 17 13:27:53 PDT 2009
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-rc5 root=/dev/sda3 ro debug
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 0000000080000000 (usable)
[ 0.000000] BIOS-e820: 0000000080000000 - 0000000090000000 (reserved)
[ 0.000000] BIOS-e820: 0000000090000000 - 00000000be825000 (usable)
[ 0.000000] BIOS-e820: 00000000be825000 - 00000000be829000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000be829000 - 00000000be841000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000be841000 - 00000000bea42000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bea42000 - 00000000bfec6000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bfec6000 - 00000000bfec8000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bfec8000 - 00000000bfec9000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bfec9000 - 00000000bfecb000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bfecb000 - 00000000bfecd000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bfecd000 - 00000000bfedf000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bfedf000 - 00000000bfef9000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bfef9000 - 00000000bfeff000 (reserved)
[ 0.000000] BIOS-e820: 00000000bfeff000 - 00000000bff00000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000d3500000 - 00000000d3501000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[ 0.000000] DMI 2.4 present.
[ 0.000000] last_pfn = 0x140000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-FFFFF uncachable
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 disabled
[ 0.000000] 1 base 000000000 mask F80000000 write-back
[ 0.000000] 2 base 080000000 mask FC0000000 write-back
[ 0.000000] 3 base 100000000 mask FC0000000 write-back
[ 0.000000] 4 base 0BFF00000 mask FFFF00000 uncachable
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820 update range: 00000000bff00000 - 0000000100000000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xbe825 max_arch_pfn = 0x400000000
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] init_memory_mapping: 0000000000000000-00000000be825000
[ 0.000000] 0000000000 - 00be800000 page 2M
[ 0.000000] 00be800000 - 00be825000 page 4k
[ 0.000000] kernel direct mapping tables up to be825000 @ 8000-d000
[ 0.000000] init_memory_mapping: 0000000100000000-0000000140000000
[ 0.000000] 0100000000 - 0140000000 page 2M
[ 0.000000] kernel direct mapping tables up to 140000000 @ b000-11000
[ 0.000000] ACPI: RSDP 00000000000fe020 00024 (v02 APPLE )
[ 0.000000] ACPI: XSDT 00000000bfeee1c0 00074 (v01 APPLE Apple00 0000008D 01000013)
[ 0.000000] ACPI: FACP 00000000bfeec000 000F4 (v03 APPLE Apple00 0000008D Loki 0000005F)
[ 0.000000] ACPI: DSDT 00000000bfee0000 0557B (v01 APPLE iMac 00090001 INTL 20061109)
[ 0.000000] ACPI: FACS 00000000bfecd000 00040
[ 0.000000] ACPI: HPET 00000000bfeeb000 00038 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: APIC 00000000bfeea000 00068 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: MCFG 00000000bfee9000 0003C (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: ASF! 00000000bfee8000 000A5 (v32 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: SBST 00000000bfee7000 00030 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: ECDT 00000000bfee6000 00053 (v01 APPLE Apple00 00000001 Loki 0000005F)
[ 0.000000] ACPI: SSDT 00000000bfec8000 004DC (v01 APPLE CpuPm 00003000 INTL 20061109)
[ 0.000000] ACPI: SSDT 00000000bfedf000 000A5 (v01 SataRe SataPri 00001000 INTL 20061109)
[ 0.000000] ACPI: SSDT 00000000bfecc000 0009F (v01 SataRe SataSec 00001000 INTL 20061109)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] (7 early reservations) ==> bootmem [0000000000 - 0140000000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
[ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
[ 0.000000] #2 [0001000000 - 000179dba0] TEXT DATA BSS ==> [0001000000 - 000179dba0]
[ 0.000000] #3 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
[ 0.000000] #4 [000179e000 - 000179e1fd] BRK ==> [000179e000 - 000179e1fd]
[ 0.000000] #5 [0000008000 - 000000b000] PGTABLE ==> [0000008000 - 000000b000]
[ 0.000000] #6 [000000b000 - 000000c000] PGTABLE ==> [000000b000 - 000000c000]
[ 0.000000] [ffffea0000000000-ffffea00045fffff] PMD -> [ffff880028600000-ffff88002bbfffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000000 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x00140000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[4] active PFN ranges
[ 0.000000] 0: 0x00000000 -> 0x0000009f
[ 0.000000] 0: 0x00000100 -> 0x00080000
[ 0.000000] 0: 0x00090000 -> 0x000be825
[ 0.000000] 0: 0x00100000 -> 0x00140000
[ 0.000000] On node 0 totalpages: 976836
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 103 pages reserved
[ 0.000000] DMA zone: 3840 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14280 pages used for memmap
[ 0.000000] DMA32 zone: 696413 pages, LIFO batch:31
[ 0.000000] Normal zone: 3584 pages used for memmap
[ 0.000000] Normal zone: 258560 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000
[ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 24
[ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 0000000080000000 - 0000000090000000
[ 0.000000] PM: Registered nosave memory: 00000000be825000 - 00000000be829000
[ 0.000000] PM: Registered nosave memory: 00000000be829000 - 00000000be841000
[ 0.000000] PM: Registered nosave memory: 00000000be841000 - 00000000bea42000
[ 0.000000] PM: Registered nosave memory: 00000000bea42000 - 00000000bfec6000
[ 0.000000] PM: Registered nosave memory: 00000000bfec6000 - 00000000bfec8000
[ 0.000000] PM: Registered nosave memory: 00000000bfec8000 - 00000000bfec9000
[ 0.000000] PM: Registered nosave memory: 00000000bfec9000 - 00000000bfecb000
[ 0.000000] PM: Registered nosave memory: 00000000bfecb000 - 00000000bfecd000
[ 0.000000] PM: Registered nosave memory: 00000000bfecd000 - 00000000bfedf000
[ 0.000000] PM: Registered nosave memory: 00000000bfedf000 - 00000000bfef9000
[ 0.000000] PM: Registered nosave memory: 00000000bfef9000 - 00000000bfeff000
[ 0.000000] PM: Registered nosave memory: 00000000bfeff000 - 00000000bff00000
[ 0.000000] PM: Registered nosave memory: 00000000bff00000 - 00000000d3500000
[ 0.000000] PM: Registered nosave memory: 00000000d3500000 - 00000000d3501000
[ 0.000000] PM: Registered nosave memory: 00000000d3501000 - 00000000f0000000
[ 0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000f4000000
[ 0.000000] PM: Registered nosave memory: 00000000f4000000 - 00000000fec00000
[ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fee00000
[ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ffc00000
[ 0.000000] PM: Registered nosave memory: 00000000ffc00000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at d3501000 (gap: d3501000:1caff000)
[ 0.000000] NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 28 pages at ffff880028037000, static data 84320 bytes
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 958813
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-rc5 root=/dev/sda3 ro debug
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.000000] Initializing CPU#0
[ 0.000000] xsave/xrstor: enabled xstate_bv 0x3, cntxt size 0x240
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.000000] Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000
[ 0.000000] software IO TLB at phys 0x20000000 - 0x24000000
[ 0.000000] Memory: 3770696k/5242880k available (4331k kernel code, 1335536k absent, 135736k reserved, 2189k data, 456k init)
[ 0.000000] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] NR_IRQS:320
[ 0.000000] Extended CMOS year: 2000
[ 0.000000] Fast TSC calibration using PIT
[ 0.000000] Detected 2653.127 MHz processor.
[ 0.000017] spurious 8259A interrupt: IRQ7.
[ 0.000999] Console: colour VGA+ 80x25
[ 0.000999] console [tty0] enabled
[ 0.000999] hpet clockevent registered
[ 0.000999] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[ 0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 5306.25 BogoMIPS (lpj=2653127)
[ 0.001302] Security Framework initialized
[ 0.001546] SELinux: Initializing.
[ 0.001804] SELinux: Starting in permissive mode
[ 0.002019] Mount-cache hash table entries: 256
[ 0.002754] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.003003] CPU: L2 cache: 6144K
[ 0.003242] CPU: Physical Processor ID: 0
[ 0.003473] CPU: Processor Core ID: 0
[ 0.003712] mce: CPU supports 6 MCE banks
[ 0.004010] CPU0: Thermal monitoring enabled (TM2)
[ 0.004252] using mwait in idle threads.
[ 0.004510] ACPI: Core revision 20090521
[ 0.045155] Setting APIC routing to flat
[ 0.045783] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.056054] CPU0: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz stepping 0a
[ 0.056991] Booting processor 1 APIC 0x1 ip 0x6000
[ 0.000999] Initializing CPU#1
[ 0.000999] Calibrating delay using timer specific routine.. 5306.29 BogoMIPS (lpj=2653148)
[ 0.000999] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.000999] CPU: L2 cache: 6144K
[ 0.000999] CPU: Physical Processor ID: 0
[ 0.000999] CPU: Processor Core ID: 1
[ 0.000999] mce: CPU supports 6 MCE banks
[ 0.000999] CPU1: Thermal monitoring enabled (TM2)
[ 0.000999] x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
[ 0.129402] CPU1: Intel(R) Core(TM)2 Duo CPU E8135 @ 2.66GHz stepping 0a
[ 0.130988] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[ 0.132011] Brought up 2 CPUs
[ 0.132249] Total of 2 processors activated (10612.55 BogoMIPS).
[ 0.132596] CPU0 attaching sched-domain:
[ 0.132984] domain 0: span 0-1 level MC
[ 0.133269] groups: 0 1
[ 0.133643] CPU1 attaching sched-domain:
[ 0.133982] domain 0: span 0-1 level MC
[ 0.134265] groups: 1 0
[ 0.137080] NET: Registered protocol family 16
[ 0.139020] ACPI: bus type pci registered
[ 0.139304] PCI: Using configuration type 1 for base access
[ 0.154993] bio: create slab <bio-0> at 0
[ 0.158399] ACPI: EC: EC description table is found, configuring boot EC
[ 0.159182] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 0.173541] ACPI: BIOS _OSI(Linux) query ignored
[ 0.176553] ACPI: Interpreter enabled
[ 0.176791] ACPI: (supports S0 S3 S4 S5)
[ 0.177344] ACPI: Using IOAPIC for interrupt routing
[ 0.227562] ACPI: EC: GPE = 0x3f, I/O: command/status = 0x66, data = 0x62
[ 0.227968] ACPI: EC: driver started in interrupt mode
[ 0.230071] ACPI: No dock devices found.
[ 0.231899] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.232228] pci 0000:00:03.0: reg 10 io port: [0x2000-0x20ff]
[ 0.232971] pci 0000:00:03.2: reg 10 io port: [0x2180-0x21bf]
[ 0.233228] pci 0000:00:03.2: reg 20 io port: [0x2140-0x217f]
[ 0.233473] pci 0000:00:03.2: reg 24 io port: [0x2100-0x213f]
[ 0.233738] pci 0000:00:03.2: PME# supported from D3hot D3cold
[ 0.233990] pci 0000:00:03.2: PME# disabled
[ 0.234442] pci 0000:00:03.5: reg 10 32bit mmio: [0xd3500000-0xd357ffff]
[ 0.234789] pci 0000:00:04.0: reg 10 32bit mmio: [0xd3588000-0xd3588fff]
[ 0.235001] pci 0000:00:04.0: supports D1 D2
[ 0.235241] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.235485] pci 0000:00:04.0: PME# disabled
[ 0.235758] pci 0000:00:04.1: reg 10 32bit mmio: [0xd3589200-0xd35892ff]
[ 0.236007] pci 0000:00:04.1: supports D1 D2
[ 0.236241] pci 0000:00:04.1: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.236485] pci 0000:00:04.1: PME# disabled
[ 0.236768] pci 0000:00:06.0: reg 10 32bit mmio: [0xd3587000-0xd3587fff]
[ 0.237001] pci 0000:00:06.0: supports D1 D2
[ 0.237240] pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.237478] pci 0000:00:06.0: PME# disabled
[ 0.237756] pci 0000:00:06.1: reg 10 32bit mmio: [0xd3589100-0xd35891ff]
[ 0.238007] pci 0000:00:06.1: supports D1 D2
[ 0.238247] pci 0000:00:06.1: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.238491] pci 0000:00:06.1: PME# disabled
[ 0.238983] pci 0000:00:08.0: reg 10 32bit mmio: [0xd3580000-0xd3583fff]
[ 0.239261] pci 0000:00:08.0: PME# supported from D3hot D3cold
[ 0.239497] pci 0000:00:08.0: PME# disabled
[ 0.239819] pci 0000:00:0a.0: reg 10 32bit mmio: [0xd3586000-0xd3586fff]
[ 0.239969] pci 0000:00:0a.0: reg 14 io port: [0x21e0-0x21e7]
[ 0.240214] pci 0000:00:0a.0: reg 18 32bit mmio: [0xd3589000-0xd35890ff]
[ 0.240460] pci 0000:00:0a.0: reg 1c 32bit mmio: [0xd3589300-0xd358930f]
[ 0.240726] pci 0000:00:0a.0: supports D1 D2
[ 0.240966] pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.241204] pci 0000:00:0a.0: PME# disabled
[ 0.241483] pci 0000:00:0b.0: reg 10 io port: [0x21d8-0x21df]
[ 0.241728] pci 0000:00:0b.0: reg 14 io port: [0x21ec-0x21ef]
[ 0.241969] pci 0000:00:0b.0: reg 18 io port: [0x21d0-0x21d7]
[ 0.242213] pci 0000:00:0b.0: reg 1c io port: [0x21e8-0x21eb]
[ 0.242451] pci 0000:00:0b.0: reg 20 io port: [0x21c0-0x21cf]
[ 0.242695] pci 0000:00:0b.0: reg 24 32bit mmio: [0xd3584000-0xd3585fff]
[ 0.243193] pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.243442] pci 0000:00:0c.0: PME# disabled
[ 0.243762] pci 0000:00:10.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.243966] pci 0000:00:10.0: PME# disabled
[ 0.244421] pci 0000:00:15.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.244669] pci 0000:00:15.0: PME# disabled
[ 0.245198] pci 0000:00:16.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.245445] pci 0000:00:16.0: PME# disabled
[ 0.245783] pci 0000:00:09.0: transparent bridge
[ 0.245968] pci 0000:00:09.0: bridge 32bit mmio: [0xd3400000-0xd34fffff]
[ 0.246288] pci 0000:00:0c.0: bridge 32bit mmio: [0xd3300000-0xd33fffff]
[ 0.246594] pci 0000:03:00.0: reg 10 32bit mmio: [0xd2000000-0xd2ffffff]
[ 0.246974] pci 0000:03:00.0: reg 14 64bit mmio: [0xc0000000-0xcfffffff]
[ 0.247225] pci 0000:03:00.0: reg 1c 64bit mmio: [0xd0000000-0xd1ffffff]
[ 0.247466] pci 0000:03:00.0: reg 24 io port: [0x1000-0x107f]
[ 0.247712] pci 0000:03:00.0: reg 30 32bit mmio: [0xd3000000-0xd301ffff]
[ 0.248029] pci 0000:00:10.0: bridge io port: [0x1000-0x1fff]
[ 0.248273] pci 0000:00:10.0: bridge 32bit mmio: [0xd2000000-0xd30fffff]
[ 0.248518] pci 0000:00:10.0: bridge 64bit mmio pref: [0xc0000000-0xd1ffffff]
[ 0.248839] pci 0000:04:00.0: reg 10 64bit mmio: [0xd3200000-0xd3203fff]
[ 0.249030] pci 0000:04:00.0: supports D1 D2
[ 0.249269] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[ 0.249513] pci 0000:04:00.0: PME# disabled
[ 0.249830] pci 0000:00:15.0: bridge 32bit mmio: [0xd3200000-0xd32fffff]
[ 0.250047] pci 0000:05:00.0: reg 10 64bit mmio: [0xd3100000-0xd3100fff]
[ 0.250353] pci 0000:05:00.0: supports D1 D2
[ 0.250593] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.250967] pci 0000:05:00.0: PME# disabled
[ 0.251282] pci 0000:00:16.0: bridge 32bit mmio: [0xd3100000-0xd31fffff]
[ 0.251579] pci_bus 0000:00: on NUMA node 0
[ 0.251828] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.255062] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IXVE._PRT]
[ 0.522185] ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 10 11 14 15) *0, disabled.
[ 0.524225] ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 10 11 14 15) *0, disabled.
[ 0.526254] ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 10 11 14 15) *0, disabled.
[ 0.528280] ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 10 11 14 15) *0, disabled.
[ 0.530306] ACPI: PCI Interrupt Link [Z003] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.532422] ACPI: PCI Interrupt Link [Z004] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.534541] ACPI: PCI Interrupt Link [Z005] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.536650] ACPI: PCI Interrupt Link [Z006] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.538760] ACPI: PCI Interrupt Link [Z007] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.540860] ACPI: PCI Interrupt Link [Z008] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.542976] ACPI: PCI Interrupt Link [Z009] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.545083] ACPI: PCI Interrupt Link [Z00A] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.547196] ACPI: PCI Interrupt Link [Z00B] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.549305] ACPI: PCI Interrupt Link [Z00C] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.551414] ACPI: PCI Interrupt Link [Z00D] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.553517] ACPI: PCI Interrupt Link [Z00E] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.555611] ACPI: PCI Interrupt Link [Z00F] (IRQs 16 17 18 19 20 21 22 23) *10
[ 0.557661] ACPI: PCI Interrupt Link [Z00G] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.559755] ACPI: PCI Interrupt Link [Z00H] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.561846] ACPI: PCI Interrupt Link [Z00I] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.563945] ACPI: PCI Interrupt Link [Z00J] (IRQs 16 17 18 19 20 21 22 23) *7
[ 0.565845] ACPI: PCI Interrupt Link [Z00K] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.567960] ACPI: PCI Interrupt Link [Z00L] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.570082] ACPI: PCI Interrupt Link [Z00M] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.572186] ACPI: PCI Interrupt Link [Z00N] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.574307] ACPI: PCI Interrupt Link [Z00O] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.576415] ACPI: PCI Interrupt Link [Z00P] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.578531] ACPI: PCI Interrupt Link [Z00Q] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.580640] ACPI: PCI Interrupt Link [Z00R] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.584119] ACPI: PCI Interrupt Link [Z00S] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.586229] ACPI: PCI Interrupt Link [Z00T] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.588336] ACPI: PCI Interrupt Link [Z00U] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.590440] ACPI: PCI Interrupt Link [LSMB] (IRQs 16 17 18 19 20 21 22 23) *15
[ 0.592499] ACPI: PCI Interrupt Link [LUS0] (IRQs 16 17 18 19 20 21 22 23) *11
[ 0.594562] ACPI: PCI Interrupt Link [LUS2] (IRQs 16 17 18 19 20 21 22 23) *10
[ 0.596627] ACPI: PCI Interrupt Link [LMAC] (IRQs 16 17 18 19 20 21 22 23) *14
[ 0.598676] ACPI: PCI Interrupt Link [LAZA] (IRQs 16 17 18 19 20 21 22 23) *15
[ 0.600736] ACPI: PCI Interrupt Link [LGPU] (IRQs 16 17 18 19 20 21 22 23) *11
[ 0.602788] ACPI: PCI Interrupt Link [LPID] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.604883] ACPI: PCI Interrupt Link [LSI0] (IRQs 16 17 18 19 20 21 22 23) *11
[ 0.606959] ACPI: PCI Interrupt Link [LSI1] (IRQs 16 17 18 19 20 21 22 23) *0, disabled.
[ 0.609093] ACPI: PCI Interrupt Link [Z000] (IRQs 16 17 18 19 20 21 22 23) *7
[ 0.610986] ACPI: PCI Interrupt Link [Z001] (IRQs 16 17 18 19 20 21 22 23) *5
[ 0.612879] ACPI: PCI Interrupt Link [LPMU] (IRQs 16 17 18 19 20 21 22 23) *14
[ 0.615125] SCSI subsystem initialized
[ 0.615334] libata version 3.00 loaded.
[ 0.616144] usbcore: registered new interface driver usbfs
[ 0.616299] usbcore: registered new interface driver hub
[ 0.617085] usbcore: registered new device driver usb
[ 0.618083] PCI: Using ACPI for IRQ routing
[ 0.638106] cfg80211: Using static regulatory domain info
[ 0.638309] cfg80211: Regulatory domain: US
[ 0.638542] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 0.639004] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 0.639241] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 0.639484] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 0.639724] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 0.640003] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 0.640245] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 0.640489] cfg80211: Calling CRDA for country: US
[ 0.640766] NetLabel: Initializing
[ 0.641002] NetLabel: domain hash size = 128
[ 0.641241] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.641601] NetLabel: unlabeled traffic allowed by default
[ 0.642104] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31, 31
[ 0.642571] hpet0: 4 comparators, 64-bit 25.000000 MHz counter
[ 0.646008] Switched to high resolution mode on CPU 0
[ 0.646389] Switched to high resolution mode on CPU 1
[ 0.660046] pnp: PnP ACPI init
[ 0.660313] ACPI: bus type pnp registered
[ 0.674257] pnp: PnP ACPI: found 8 devices
[ 0.674498] ACPI: ACPI bus type pnp unregistered
[ 0.674765] system 00:01: iomem range 0xf0000000-0xf3ffffff has been reserved
[ 0.675038] system 00:04: iomem range 0xfed00000-0xfed003ff has been reserved
[ 0.675290] system 00:06: ioport range 0x400-0x47f has been reserved
[ 0.675534] system 00:06: ioport range 0x480-0x4ff has been reserved
[ 0.675778] system 00:06: ioport range 0x500-0x57f has been reserved
[ 0.676030] system 00:06: ioport range 0x580-0x5ff has been reserved
[ 0.676274] system 00:06: ioport range 0x800-0x87f has been reserved
[ 0.676518] system 00:06: ioport range 0x880-0x8ff has been reserved
[ 0.676755] system 00:06: ioport range 0x2140-0x217f has been reserved
[ 0.677005] system 00:06: ioport range 0x2100-0x213f has been reserved
[ 0.677246] system 00:06: ioport range 0x4d0-0x4d1 has been reserved
[ 0.677490] system 00:06: ioport range 0x295-0x296 has been reserved
[ 0.684445] pci 0000:00:09.0: PCI bridge, secondary bus 0000:01
[ 0.684681] pci 0000:00:09.0: IO window: disabled
[ 0.684923] pci 0000:00:09.0: MEM window: 0xd3400000-0xd34fffff
[ 0.685173] pci 0000:00:09.0: PREFETCH window: disabled
[ 0.685411] pci 0000:00:0c.0: PCI bridge, secondary bus 0000:02
[ 0.685652] pci 0000:00:0c.0: IO window: disabled
[ 0.685894] pci 0000:00:0c.0: MEM window: 0xd3300000-0xd33fffff
[ 0.686147] pci 0000:00:0c.0: PREFETCH window: disabled
[ 0.686394] pci 0000:00:10.0: PCI bridge, secondary bus 0000:03
[ 0.686629] pci 0000:00:10.0: IO window: 0x1000-0x1fff
[ 0.686872] pci 0000:00:10.0: MEM window: 0xd2000000-0xd30fffff
[ 0.687117] pci 0000:00:10.0: PREFETCH window: 0x000000c0000000-0x000000d1ffffff
[ 0.687552] pci 0000:00:15.0: PCI bridge, secondary bus 0000:04
[ 0.687786] pci 0000:00:15.0: IO window: disabled
[ 0.688040] pci 0000:00:15.0: MEM window: 0xd3200000-0xd32fffff
[ 0.688287] pci 0000:00:15.0: PREFETCH window: disabled
[ 0.688528] pci 0000:00:16.0: PCI bridge, secondary bus 0000:05
[ 0.688769] pci 0000:00:16.0: IO window: disabled
[ 0.689017] pci 0000:00:16.0: MEM window: 0xd3100000-0xd31fffff
[ 0.689264] pci 0000:00:16.0: PREFETCH window: disabled
[ 0.689512] pci 0000:00:09.0: enabling device (0000 -> 0002)
[ 0.689753] pci 0000:00:09.0: setting latency timer to 64
[ 0.690011] pci 0000:00:0c.0: enabling device (0000 -> 0002)
[ 0.692079] ACPI: PCI Interrupt Link [Z003] enabled at IRQ 23
[ 0.692327] pci 0000:00:0c.0: PCI INT A -> Link[Z003] -> GSI 23 (level, low) -> IRQ 23
[ 0.692769] pci 0000:00:0c.0: setting latency timer to 64
[ 0.693024] pci 0000:00:10.0: setting latency timer to 64
[ 0.695089] ACPI: PCI Interrupt Link [Z00F] enabled at IRQ 22
[ 0.695335] pci 0000:00:15.0: PCI INT A -> Link[Z00F] -> GSI 22 (level, low) -> IRQ 22
[ 0.695767] pci 0000:00:15.0: setting latency timer to 64
[ 0.697838] ACPI: PCI Interrupt Link [Z00J] enabled at IRQ 21
[ 0.698092] pci 0000:00:16.0: PCI INT A -> Link[Z00J] -> GSI 21 (level, low) -> IRQ 21
[ 0.698529] pci 0000:00:16.0: setting latency timer to 64
[ 0.698767] pci_bus 0000:00: resource 0 io: [0x00-0xffff]
[ 0.699014] pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff]
[ 0.699258] pci_bus 0000:01: resource 1 mem: [0xd3400000-0xd34fffff]
[ 0.699494] pci_bus 0000:01: resource 3 io: [0x00-0xffff]
[ 0.699735] pci_bus 0000:01: resource 4 mem: [0x000000-0xffffffffffffffff]
[ 0.699974] pci_bus 0000:02: resource 1 mem: [0xd3300000-0xd33fffff]
[ 0.700223] pci_bus 0000:03: resource 0 io: [0x1000-0x1fff]
[ 0.700465] pci_bus 0000:03: resource 1 mem: [0xd2000000-0xd30fffff]
[ 0.700700] pci_bus 0000:03: resource 2 pref mem [0xc0000000-0xd1ffffff]
[ 0.700944] pci_bus 0000:04: resource 1 mem: [0xd3200000-0xd32fffff]
[ 0.701189] pci_bus 0000:05: resource 1 mem: [0xd3100000-0xd31fffff]
[ 0.701488] NET: Registered protocol family 2
[ 0.701868] IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.703126] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[ 0.705102] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
[ 0.706317] TCP: Hash tables configured (established 262144 bind 65536)
[ 0.706560] TCP reno registered
[ 0.706979] NET: Registered protocol family 1
[ 0.712070] microcode: CPU0 sig=0x1067a, pf=0x80, revision=0xa07
[ 0.712319] microcode: CPU1 sig=0x1067a, pf=0x80, revision=0xa07
[ 0.712727] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 0.715672] Initializing RT-Tester: OK
[ 0.716115] audit: initializing netlink socket (disabled)
[ 0.716380] type=2000 audit(1250612259.716:1): initialized
[ 0.724486] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.752353] ROMFS MTD (C) 2007 Red Hat, Inc.
[ 0.753122] fuse init (API version 7.12)
[ 0.754458] msgmni has been set to 7366
[ 0.755093] SELinux: Registering netfilter hooks
[ 0.756636] alg: No test for stdrng (krng)
[ 0.756904] io scheduler noop registered
[ 0.757719] io scheduler cfq registered (default)
[ 0.769250] pci 0000:03:00.0: Boot video device
[ 0.790797] Linux agpgart interface v0.103
[ 0.794932] loop: module loaded
[ 0.795437] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[ 0.796878] ahci 0000:00:0b.0: version 3.0
[ 0.799124] ACPI: PCI Interrupt Link [LSI0] enabled at IRQ 20
[ 0.799375] ahci 0000:00:0b.0: PCI INT A -> Link[LSI0] -> GSI 20 (level, low) -> IRQ 20
[ 0.799857] ahci 0000:00:0b.0: irq 24 for MSI/MSI-X
[ 0.800156] ahci 0000:00:0b.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3 impl IDE mode
[ 0.800590] ahci 0000:00:0b.0: flags: 64bit ncq sntf pm led pmp pio slum part
[ 0.801023] ahci 0000:00:0b.0: setting latency timer to 64
[ 0.801480] scsi0 : ahci
[ 0.802658] scsi1 : ahci
[ 0.803373] scsi2 : ahci
[ 0.804017] scsi3 : ahci
[ 0.804652] scsi4 : ahci
[ 0.805284] scsi5 : ahci
[ 0.806603] ata1: SATA max UDMA/133 abar m8192@0xd3584000 port 0xd3584100 irq 24
[ 0.807110] ata2: SATA max UDMA/133 abar m8192@0xd3584000 port 0xd3584180 irq 24
[ 0.807541] ata3: DUMMY
[ 0.807777] ata4: DUMMY
[ 0.808020] ata5: DUMMY
[ 0.808256] ata6: DUMMY
[ 0.809092] usbcore: registered new interface driver usblcd
[ 0.809488] usbcore: registered new interface driver usbled
[ 0.810360] PNP: No PS/2 controller found. Probing ports directly.
[ 0.811471] i8042.c: No controller found.
[ 0.812211] mice: PS/2 mouse device common for all mice
[ 0.814145] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
[ 0.814578] EDAC MC: Ver: 2.1.0 Aug 17 2009
[ 0.815257] cpuidle: using governor ladder
[ 0.815491] cpuidle: using governor menu
[ 0.827551] usbcore: registered new interface driver hiddev
[ 0.827950] usbcore: registered new interface driver usbhid
[ 0.828199] usbhid: v2.6:USB HID core driver
[ 0.828628] Advanced Linux Sound Architecture Driver Version 1.0.20.
[ 0.828868] ALSA device list:
[ 0.829247] No soundcards found.
[ 0.829752] oprofile: using NMI interrupt.
[ 0.830380] IPVS: Registered protocols (TCP, UDP, AH, ESP)
[ 0.830888] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
[ 0.831525] IPVS: ipvs loaded.
[ 0.832274] Initializing XFRM netlink socket
[ 0.832528] NET: Registered protocol family 17
[ 0.832773] NET: Registered protocol family 15
[ 0.833052] lib80211: common routines for IEEE802.11 drivers
[ 0.833288] lib80211_crypt: registered algorithm 'NULL'
[ 0.833529] lib80211_crypt: registered algorithm 'WEP'
[ 0.833769] lib80211_crypt: registered algorithm 'CCMP'
[ 0.834015] lib80211_crypt: registered algorithm 'TKIP'
[ 1.266024] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.268173] ata1.00: ATA-8: WDC WD6400AAKS-40H2B0, 07.04C07, max UDMA/133
[ 1.268417] ata1.00: 1250263728 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 1.269728] ata1.00: configured for UDMA/133
[ 1.280216] scsi 0:0:0:0: Direct-Access ATA WDC WD6400AAKS-4 07.0 PQ: 0 ANSI: 5
[ 1.281489] sd 0:0:0:0: [sda] 1250263728 512-byte logical blocks: (640 GB/596 GiB)
[ 1.282070] sd 0:0:0:0: [sda] Write Protect is off
[ 1.282312] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.282620] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.283470] sda:
[ 1.283801] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 1.339348] sda1 sda2 sda3 sda4
[ 1.341212] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1.674041] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.691386] ata2.00: ATAPI: PIONEER DVD-RW DVRTS08, Q81D, max UDMA/33, ATAPI AN
[ 1.709311] ata2.00: configured for UDMA/33
[ 1.774735] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVRTS08 Q81D PQ: 0 ANSI: 5
[ 1.899541] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda caddy
[ 1.899786] Uniform CD-ROM driver Revision: 3.20
[ 1.900494] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 1.901088] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 1.956205] EXT4-fs (sda3): barriers enabled
[ 1.979375] kjournald2 starting: pid 700, dev sda3:8, commit interval 5 seconds
[ 1.979389] EXT4-fs (sda3): delayed allocation enabled
[ 1.979392] EXT4-fs: file extents enabled
[ 2.044631] EXT4-fs: mballoc enabled
[ 2.044897] EXT4-fs (sda3): mounted filesystem with ordered data mode
[ 2.045272] VFS: Mounted root (ext4 filesystem) readonly on device 8:3.
[ 2.045587] Freeing unused kernel memory: 456k freed
[ 2.303483] type=1404 audit(1250612261.303:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
[ 2.418970] SELinux: 8192 avtab hash slots, 161696 rules.
[ 2.596086] SELinux: 8192 avtab hash slots, 161696 rules.
[ 2.938351] SELinux: 7 users, 13 roles, 2910 types, 104 bools
[ 2.938641] SELinux: 74 classes, 161696 rules
[ 2.951138] SELinux: Completing initialization.
[ 2.951379] SELinux: Setting up existing superblocks.
[ 2.951631] SELinux: initialized (dev sda3, type ext4), uses xattr
[ 2.952117] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
[ 2.952589] SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
[ 2.953030] SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
[ 2.953468] SELinux: initialized (dev devpts, type devpts), uses transition SIDs
[ 2.953907] SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
[ 2.954346] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 2.954779] SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts
[ 2.955219] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[ 2.955462] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
[ 2.956347] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[ 2.956596] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 2.956849] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
[ 2.957102] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
[ 2.957536] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[ 2.979500] type=1403 audit(1250612261.979:3): policy loaded auid=4294967295 ses=4294967295
[ 3.495223] applesmc: Apple iMac detected:
[ 3.495465] applesmc: - Model without accelerometer
[ 3.495700] applesmc: - Model without light sensors and backlight
[ 3.495941] applesmc: - Model with 9 temperature sensors
[ 3.496187] Platform driver 'applesmc' needs updating - please use dev_pm_ops
[ 3.496760] applesmc: device successfully initialized.
[ 3.497816] applesmc: 3 fans found.
[ 3.498371] applesmc: driver successfully loaded.
[ 3.545891] usbcore: registered new interface driver appletouch
[ 3.567147] ACPI: SSDT 00000000bfecac18 0027A (v01 APPLE Cpu0Ist 00003000 INTL 20061109)
[ 3.569630] ACPI: SSDT 00000000bfeca918 0028F (v01 APPLE Cpu0Cst 00003001 INTL 20061109)
[ 3.571786] Monitor-Mwait will be used to enter C-1 state
[ 3.571837] Monitor-Mwait will be used to enter C-2 state
[ 3.571886] Monitor-Mwait will be used to enter C-3 state
[ 3.571903] Marking TSC unstable due to TSC halts in idle
[ 3.572939] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[ 3.573579] processor LNXCPU:00: registered as cooling_device0
[ 3.573827] ACPI: Processor [CPU0] (supports 8 throttling states)
[ 3.576719] ACPI: SSDT 00000000bfecaf18 000C8 (v01 APPLE Cpu1Ist 00003000 INTL 20061109)
[ 3.578937] ACPI: SSDT 00000000bfec9f18 00085 (v01 APPLE Cpu1Cst 00003000 INTL 20061109)
[ 3.582416] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
[ 3.583002] processor LNXCPU:01: registered as cooling_device1
[ 3.583269] ACPI: Processor [CPU1] (supports 8 throttling states)
[ 3.709014] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 3.731751] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 3.732895] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
[ 3.733333] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
[ 3.733768] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[ 3.743827] arp_tables: (C) 2002 David S. Miller
[ 3.774882] usbcore: registered new interface driver isight_firmware
[ 3.802811] ipmi message handler version 39.2
[ 3.805401] IPMI Watchdog: driver initialized
[ 3.828917] Bluetooth: Core ver 2.15
[ 3.829441] NET: Registered protocol family 31
[ 3.829674] Bluetooth: HCI device and connection manager initialized
[ 3.829917] Bluetooth: HCI socket layer initialized
[ 3.841719] Bluetooth: L2CAP ver 2.13
[ 3.841959] Bluetooth: L2CAP socket layer initialized
[ 3.846334] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 3.851566] Bluetooth: Generic Bluetooth USB driver ver 0.5
[ 3.851987] usbcore: registered new interface driver btusb
[ 3.867591] Bluetooth: RFCOMM socket layer initialized
[ 3.867853] Bluetooth: RFCOMM TTY layer initialized
[ 3.868110] Bluetooth: RFCOMM ver 1.11
[ 3.874324] Bluetooth: HCI UART driver ver 2.2
[ 3.874565] Bluetooth: HCI H4 protocol initialized
[ 3.874805] Bluetooth: HCI BCSP protocol initialized
[ 3.880393] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.882769] ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 19
[ 3.883025] ehci_hcd 0000:00:04.1: PCI INT B -> Link[LUS2] -> GSI 19 (level, low) -> IRQ 19
[ 3.883513] ehci_hcd 0000:00:04.1: setting latency timer to 64
[ 3.883518] ehci_hcd 0000:00:04.1: EHCI Host Controller
[ 3.883773] ehci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 1
[ 3.884290] ehci_hcd 0000:00:04.1: debug port 1
[ 3.884540] ehci_hcd 0000:00:04.1: cache line size of 32 is not supported
[ 3.884576] ehci_hcd 0000:00:04.1: irq 19, io mem 0xd3589200
[ 3.890091] ehci_hcd 0000:00:04.1: USB 2.0 started, EHCI 1.00
[ 3.890709] usb usb1: configuration #1 chosen from 1 choice
[ 3.891209] hub 1-0:1.0: USB hub found
[ 3.891468] hub 1-0:1.0: 7 ports detected
[ 3.893922] ACPI: PCI Interrupt Link [Z001] enabled at IRQ 18
[ 3.894185] ehci_hcd 0000:00:06.1: PCI INT B -> Link[Z001] -> GSI 18 (level, low) -> IRQ 18
[ 3.894631] ehci_hcd 0000:00:06.1: setting latency timer to 64
[ 3.894636] ehci_hcd 0000:00:06.1: EHCI Host Controller
[ 3.894894] ehci_hcd 0000:00:06.1: new USB bus registered, assigned bus number 2
[ 3.895395] ehci_hcd 0000:00:06.1: debug port 1
[ 3.895638] ehci_hcd 0000:00:06.1: cache line size of 32 is not supported
[ 3.895676] ehci_hcd 0000:00:06.1: irq 18, io mem 0xd3589100
[ 3.901093] ehci_hcd 0000:00:06.1: USB 2.0 started, EHCI 1.00
[ 3.901720] usb usb2: configuration #1 chosen from 1 choice
[ 3.902191] hub 2-0:1.0: USB hub found
[ 3.902449] hub 2-0:1.0: 5 ports detected
[ 3.907889] uhci_hcd: USB Universal Host Controller Interface driver
[ 3.941540] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4.000113] Clocksource tsc unstable (delta = -209840738 ns)
[ 4.124394] udev: starting version 145
[ 4.190743] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 4.191174] ACPI: Power Button [PWRF]
[ 4.191576] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2
[ 4.199473] ACPI: Power Button [PWRB]
[ 4.199848] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3
[ 4.200294] ACPI: Sleep Button [SLPB]
[ 4.200631] usb 1-1: new high speed USB device using ehci_hcd and address 2
[ 4.323737] usb 1-1: configuration #1 chosen from 1 choice
[ 4.324138] hub 1-1:1.0: USB hub found
[ 4.324457] hub 1-1:1.0: 3 ports detected
[ 4.350547] wl: module license '' taints kernel.
[ 4.350784] Disabling lock debugging due to kernel taint
[ 4.352753] wl 0000:04:00.0: power state changed by ACPI to D0
[ 4.353012] wl 0000:04:00.0: PCI INT A -> Link[Z00F] -> GSI 22 (level, low) -> IRQ 22
[ 4.353441] wl 0000:04:00.0: setting latency timer to 64
[ 4.370286] eth0: Broadcom BCM432b 802.11 Wireless Controller 5.10.79.10
[ 4.428718] ohci1394 0000:05:00.0: PCI INT A -> Link[Z00J] -> GSI 21 (level, low) -> IRQ 21
[ 4.429163] ohci1394 0000:05:00.0: setting latency timer to 64
[ 4.429443] usb 1-4: new high speed USB device using ehci_hcd and address 3
[ 4.486636] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[21] MMIO=[d3100000-d31007ff] Max Packet=[4096] IR/IT contexts=[8/8]
[ 4.499709] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 17
[ 4.499947] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 17 (level, low) -> IRQ 17
[ 4.500535] HDA Intel 0000:00:08.0: setting latency timer to 64
[ 4.502488] udev: renamed network interface eth0 to eth1
[ 4.557930] usb 1-4: configuration #1 chosen from 1 choice
[ 4.734283] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:08.0/input/input4
[ 4.782491] usb 1-1.2: new low speed USB device using ehci_hcd and address 5
[ 4.877535] usb 1-1.2: configuration #1 chosen from 1 choice
[ 4.882082] input: Apple Inc. Apple Keyboard as /devices/pci0000:00/0000:00:04.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input5
[ 4.882645] apple 0003:05AC:021D.0001: input: USB HID v1.11 Keyboard [Apple Inc. Apple Keyboard] on usb-0000:00:04.1-1.2/input0
[ 4.886486] input: Apple Inc. Apple Keyboard as /devices/pci0000:00/0000:00:04.1/usb1/1-1/1-1.2/1-1.2:1.1/input/input6
[ 4.887027] apple 0003:05AC:021D.0002: input: USB HID v1.11 Device [Apple Inc. Apple Keyboard] on usb-0000:00:04.1-1.2/input1
[ 4.953976] usb 1-1.3: new low speed USB device using ehci_hcd and address 6
[ 5.048906] usb 1-1.3: configuration #1 chosen from 1 choice
[ 5.051462] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16
[ 5.051704] nvidia 0000:03:00.0: PCI INT A -> Link[LGPU] -> GSI 16 (level, low) -> IRQ 16
[ 5.051986] input: Mitsumi Electric Apple Optical USB Mouse as /devices/pci0000:00/0000:00:04.1/usb1/1-1/1-1.3/1-1.3:1.0/input/input7
[ 5.052104] apple 0003:05AC:0304.0003: input: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-0000:00:04.1-1.3/input0
[ 5.053122] nvidia 0000:03:00.0: setting latency timer to 64
[ 5.053580] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 17:52:27 PDT 2009
[ 5.370139] Adding 26440420k swap on /dev/sda4. Priority:1 extents:1 across:26440420k
[ 5.474171] EXT4-fs (sda3): internal journal on sda3:8
[ 5.505264] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 5.757474] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0023dffffea82aaa]
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 16:24 ` Justin Mattock
@ 2009-08-18 19:57 ` Steven Rostedt
2009-08-18 20:06 ` Justin P. Mattock
2009-08-18 23:29 ` Steven Rostedt
1 sibling, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-08-18 19:57 UTC (permalink / raw)
To: Justin Mattock; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2289 bytes --]
On Tue, 18 Aug 2009, Justin Mattock wrote:
> On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
> > On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
> >> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
> >> > I posted already and had no reply,
> >> > I cannot boot my system with the latest git
> >> >
> >> > seems to be stuck in some lock:
> >> >
> >> > [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
> >> > [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
> >> > [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
> >> > [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
> >> > [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
> >> > [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
> >> > [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
> >> > [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
> >> > [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
> >> > [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
> >> > [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
> >> > [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
> >> > [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
> >> > [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
> >> > [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
> >>
> >>
> >>
> >> Ouch...
> >>
> >> I've never seen such panic. Could you send me your config, hopefully
> >> I could reproduce it?
> >
> > Send me the config too please.
> >
> > -- Steve
> >
> >
>
> yeah this happens with rc6 but not with rc5.
>
> The system is a linux from scratch build
> x86_64 I used these flags for building everything:
>
> CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
> -fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>
> also: I have a macbook(not x86_64) that is running rc6 that seems
> to be fine.(I can double check).
>
> attached is .config, dmesg as well.
I used your config and I can not reproduce the bug you have. Was this a
constant issue? That is, was it reproducible at every boot?
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 19:57 ` Steven Rostedt
@ 2009-08-18 20:06 ` Justin P. Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-18 20:06 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 18 Aug 2009, Justin Mattock wrote:
>
>
>> On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
>>
>>> On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
>>>
>>>> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
>>>>
>>>>> I posted already and had no reply,
>>>>> I cannot boot my system with the latest git
>>>>>
>>>>> seems to be stuck in some lock:
>>>>>
>>>>> [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
>>>>> [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
>>>>> [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
>>>>> [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
>>>>> [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
>>>>> [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
>>>>> [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
>>>>> [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
>>>>> [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
>>>>> [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
>>>>> [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
>>>>> [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
>>>>> [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
>>>>> [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
>>>>> [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
>>>>>
>>>>
>>>> Ouch...
>>>>
>>>> I've never seen such panic. Could you send me your config, hopefully
>>>> I could reproduce it?
>>>>
>>> Send me the config too please.
>>>
>>> -- Steve
>>>
>>>
>>>
>> yeah this happens with rc6 but not with rc5.
>>
>> The system is a linux from scratch build
>> x86_64 I used these flags for building everything:
>>
>> CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
>> -fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>
>> also: I have a macbook(not x86_64) that is running rc6 that seems
>> to be fine.(I can double check).
>>
>> attached is .config, dmesg as well.
>>
>
> I used your config and I can not reproduce the bug you have. Was this a
> constant issue? That is, was it reproducible at every boot?
>
> -- Steve
yes.
every boot this shows up.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 16:24 ` Justin Mattock
2009-08-18 19:57 ` Steven Rostedt
@ 2009-08-18 23:29 ` Steven Rostedt
2009-08-18 23:55 ` Justin P. Mattock
2009-08-19 0:23 ` Justin P. Mattock
1 sibling, 2 replies; 62+ messages in thread
From: Steven Rostedt @ 2009-08-18 23:29 UTC (permalink / raw)
To: Justin Mattock; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2479 bytes --]
On Tue, 18 Aug 2009, Justin Mattock wrote:
> On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
> > On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
> >> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
> >> > I posted already and had no reply,
> >> > I cannot boot my system with the latest git
> >> >
> >> > seems to be stuck in some lock:
BTW, it does not look like it got stuck in a lock. The backtrace shows
that it paniced inside event_create_dir due to a bad pointer.
> >> >
> >> > [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
> >> > [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
> >> > [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
> >> > [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
> >> > [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
> >> > [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
> >> > [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
> >> > [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
> >> > [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
> >> > [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
> >> > [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
> >> > [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
> >> > [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
> >> > [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
> >> > [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
> >>
> >>
> >>
> >> Ouch...
> >>
> >> I've never seen such panic. Could you send me your config, hopefully
> >> I could reproduce it?
> >
> > Send me the config too please.
> >
> > -- Steve
> >
> >
>
> yeah this happens with rc6 but not with rc5.
>
> The system is a linux from scratch build
> x86_64 I used these flags for building everything:
>
> CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
> -fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>
> also: I have a macbook(not x86_64) that is running rc6 that seems
> to be fine.(I can double check).
>
> attached is .config, dmesg as well.
BTW, how did you get the dmesg? Is it from a clean boot?
Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
on it? It shouldn't take too long.
Thanks,
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 23:29 ` Steven Rostedt
@ 2009-08-18 23:55 ` Justin P. Mattock
2009-08-19 0:23 ` Justin P. Mattock
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-18 23:55 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 18 Aug 2009, Justin Mattock wrote:
>
>
>> On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
>>
>>> On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
>>>
>>>> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
>>>>
>>>>> I posted already and had no reply,
>>>>> I cannot boot my system with the latest git
>>>>>
>>>>> seems to be stuck in some lock:
>>>>>
>
> BTW, it does not look like it got stuck in a lock. The backtrace shows
> that it paniced inside event_create_dir due to a bad pointer.
>
>
>>>>> [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
>>>>> [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
>>>>> [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
>>>>> [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
>>>>> [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
>>>>> [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
>>>>> [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
>>>>> [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
>>>>> [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
>>>>> [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
>>>>> [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
>>>>> [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
>>>>> [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
>>>>> [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
>>>>> [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
>>>>>
>>>>
>>>> Ouch...
>>>>
>>>> I've never seen such panic. Could you send me your config, hopefully
>>>> I could reproduce it?
>>>>
>>> Send me the config too please.
>>>
>>> -- Steve
>>>
>>>
>>>
>> yeah this happens with rc6 but not with rc5.
>>
>> The system is a linux from scratch build
>> x86_64 I used these flags for building everything:
>>
>> CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
>> -fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>
>> also: I have a macbook(not x86_64) that is running rc6 that seems
>> to be fine.(I can double check).
>>
>> attached is .config, dmesg as well.
>>
>
> BTW, how did you get the dmesg? Is it from a clean boot?
>
> Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
> on it? It shouldn't take too long.
>
> Thanks,
>
> -- Steve
>
>
dmesg is from rc5 figured it would be good to
send that.
as for whatever is happening with this I don't really know.
The problem with doing a git bisect is these kernels
are tar.balls although I do have a fresh pulled
tree which might work.
if not Ill just start reverting
commits from the web interface until she boots properly.
(luckily its from rc5 to rc6)
At the moment I'm trying to get the grub2 properly configured
so I can get more of this message on the screen. and then manually
write it down.
(have to learn the new gfxload thing).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-18 23:29 ` Steven Rostedt
2009-08-18 23:55 ` Justin P. Mattock
@ 2009-08-19 0:23 ` Justin P. Mattock
2009-08-19 0:31 ` Steven Rostedt
2009-08-19 1:10 ` Li Zefan
1 sibling, 2 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-19 0:23 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 18 Aug 2009, Justin Mattock wrote:
>
>
>> On Tue, Aug 18, 2009 at 9:09 AM, Steven Rostedt<rostedt@goodmis.org> wrote:
>>
>>> On Tue, Aug 18, 2009 at 12:49:06PM +0200, Frederic Weisbecker wrote:
>>>
>>>> On Thu, Aug 13, 2009 at 08:42:21AM -0700, Justin P. Mattock wrote:
>>>>
>>>>> I posted already and had no reply,
>>>>> I cannot boot my system with the latest git
>>>>>
>>>>> seems to be stuck in some lock:
>>>>>
>
> BTW, it does not look like it got stuck in a lock. The backtrace shows
> that it paniced inside event_create_dir due to a bad pointer.
>
>
>>>>> [ 0.655640] [<ffffffff81440c33>] panic+0x84/0x129
>>>>> [ 0.655883] [<ffffffff81063f96>] do_exit+0x84/0x67e
>>>>> [ 0.656125] [<ffffffff81445044>] oops_end+0x9c/0xb7
>>>>> [ 0.656368] [<ffffffff81044a6c>] no_context+0x200/0x223
>>>>> [ 0.656611] [<ffffffff81442d3d>] ? __mutex_lock_slowpath+0x226/0x249
>>>>> [ 0.656848] [<ffffffff81044c36>] __bad_area_nosemaphore+0x1a7/0x1e1
>>>>> [ 0.657097] [<ffffffff81442b01>]? mutex_unlock+0x1c/0x32
>>>>> [ 0.657097] [<ffffffff811ce094>] ? inode_doinit_with_dentry+0x533/0x5be
>>>>> [ 0.657579] [<ffffffff81443ee0>] ? _spin_unlock+0x1c/0x32
>>>>> [ 0.657822] [<ffffffff81044c91>] bad_area_nosemaphore+0x2a/0x40
>>>>> [ 0.658066] [<ffffffff811ce149>] ? selinux_d_instantiate+0x2a/0x40
>>>>> [ 0.658309] [<ffffffff8144687d>] do_page_fault+0x192/0x2dd
>>>>> [ 0.658549] [<ffffffff814444cf>] page_fault+0x1f/0x30
>>>>> [ 0.658791] [<ffffffff8120e856>] ? strcmp+0x17/0x46
>>>>> [ 0.659040] [<ffffffff810b9ca0>] event_create_dir+0x49/0x37b
>>>>>
>>>>
>>>> Ouch...
>>>>
>>>> I've never seen such panic. Could you send me your config, hopefully
>>>> I could reproduce it?
>>>>
>>> Send me the config too please.
>>>
>>> -- Steve
>>>
>>>
>>>
>> yeah this happens with rc6 but not with rc5.
>>
>> The system is a linux from scratch build
>> x86_64 I used these flags for building everything:
>>
>> CFLAGS=" -m64 -mtune=core2 -march=core2 -mfpmath=both -O2 -pipe
>> -fomit-frame-pointer -fstack-protector" CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>
>> also: I have a macbook(not x86_64) that is running rc6 that seems
>> to be fine.(I can double check).
>>
>> attached is .config, dmesg as well.
>>
>
> BTW, how did you get the dmesg? Is it from a clean boot?
>
> Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
> on it? It shouldn't take too long.
>
> Thanks,
>
> -- Steve
>
>
well grub2 sure works o.k.
the new gfxload is pretty good.
problem is the screen just says
[Linux-bzImage etc.....]
and that's it. (was hoping to make the
font smaller to reveal the bug).
at this point the only choice I have is to undo
commits until I hit the right one.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-19 0:23 ` Justin P. Mattock
@ 2009-08-19 0:31 ` Steven Rostedt
2009-08-19 1:18 ` Justin P. Mattock
2009-08-19 1:10 ` Li Zefan
1 sibling, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-08-19 0:31 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
On Tue, 18 Aug 2009, Justin P. Mattock wrote:
> well grub2 sure works o.k.
> the new gfxload is pretty good.
> problem is the screen just says
> [Linux-bzImage etc.....]
> and that's it. (was hoping to make the
> font smaller to reveal the bug).
>
> at this point the only choice I have is to undo
> commits until I hit the right one.
How come you can not do a git bisect?
It would be faster.
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-19 0:23 ` Justin P. Mattock
2009-08-19 0:31 ` Steven Rostedt
@ 2009-08-19 1:10 ` Li Zefan
2009-08-20 5:51 ` Justin P. Mattock
2009-08-22 7:48 ` Justin P. Mattock
1 sibling, 2 replies; 62+ messages in thread
From: Li Zefan @ 2009-08-19 1:10 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Steven Rostedt, Frederic Weisbecker, Linux Kernel Mailing List
>> BTW, how did you get the dmesg? Is it from a clean boot?
>>
>> Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
>> on it? It shouldn't take too long.
>>
>> Thanks,
>>
>> -- Steve
>>
>>
> well grub2 sure works o.k.
> the new gfxload is pretty good.
> problem is the screen just says
> [Linux-bzImage etc.....]
> and that's it. (was hoping to make the
> font smaller to reveal the bug).
>
> at this point the only choice I have is to undo
> commits until I hit the right one.
>
You still can do bisect manually. or use quilt?
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-19 0:31 ` Steven Rostedt
@ 2009-08-19 1:18 ` Justin P. Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-19 1:18 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 18 Aug 2009, Justin P. Mattock wrote:
>
>> well grub2 sure works o.k.
>> the new gfxload is pretty good.
>> problem is the screen just says
>> [Linux-bzImage etc.....]
>> and that's it. (was hoping to make the
>> font smaller to reveal the bug).
>>
>> at this point the only choice I have is to undo
>> commits until I hit the right one.
>>
>
> How come you can not do a git bisect?
>
> It would be faster.
>
> -- Steve
>
>
>
I'll give it a try
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-19 1:10 ` Li Zefan
@ 2009-08-20 5:51 ` Justin P. Mattock
2009-08-22 7:48 ` Justin P. Mattock
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-20 5:51 UTC (permalink / raw)
To: Li Zefan; +Cc: Steven Rostedt, Frederic Weisbecker, Linux Kernel Mailing List
Li Zefan wrote:
>>> BTW, how did you get the dmesg? Is it from a clean boot?
>>>
>>> Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
>>> on it? It shouldn't take too long.
>>>
>>> Thanks,
>>>
>>> -- Steve
>>>
>>>
>>>
>> well grub2 sure works o.k.
>> the new gfxload is pretty good.
>> problem is the screen just says
>> [Linux-bzImage etc.....]
>> and that's it. (was hoping to make the
>> font smaller to reveal the bug).
>>
>> at this point the only choice I have is to undo
>> commits until I hit the right one.
>>
>>
>
> You still can do bisect manually. or use quilt?
>
>
>
after going schizo with reverting patches,
I've come down to thinking that this freeze might
have to do with the tracer merge that happened
a few days ago. (been avoiding that one) I'll have
to revert (If I can) the whole thing to see if this
machine boot's with rc6.
As for perf I reverted everything
up to rc5, and the machine still sticks telling me that
might not be the issue.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-19 1:10 ` Li Zefan
2009-08-20 5:51 ` Justin P. Mattock
@ 2009-08-22 7:48 ` Justin P. Mattock
2009-08-24 2:41 ` Li Zefan
2009-08-24 19:42 ` Steven Rostedt
1 sibling, 2 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-22 7:48 UTC (permalink / raw)
To: Li Zefan; +Cc: Steven Rostedt, Frederic Weisbecker, Linux Kernel Mailing List
Li Zefan wrote:
>>> BTW, how did you get the dmesg? Is it from a clean boot?
>>>
>>> Since it works fine in -rc5 but breaks in -rc6, could you do a git bisect
>>> on it? It shouldn't take too long.
>>>
>>> Thanks,
>>>
>>> -- Steve
>>>
>>>
>>>
>> well grub2 sure works o.k.
>> the new gfxload is pretty good.
>> problem is the screen just says
>> [Linux-bzImage etc.....]
>> and that's it. (was hoping to make the
>> font smaller to reveal the bug).
>>
>> at this point the only choice I have is to undo
>> commits until I hit the right one.
>>
>>
>
> You still can do bisect manually. or use quilt?
>
>
>
Hey alright 2.6.31-rc6 booted.
I must admit, I've been afraid of doing
a git bisect for some time now. but after learning
to do a bisect, I cant see a better solution to finding a
bug(biggest issue I see is having a huge .config).
Anyways the culprit for my issue is this commit:
af6af30c0fcd77e621638e53ef8b176bca8bd3b4
reverting this on rc6 booted the machine up.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-22 7:48 ` Justin P. Mattock
@ 2009-08-24 2:41 ` Li Zefan
2009-08-24 3:07 ` Justin P. Mattock
2009-08-24 5:58 ` Peter Zijlstra
2009-08-24 19:42 ` Steven Rostedt
1 sibling, 2 replies; 62+ messages in thread
From: Li Zefan @ 2009-08-24 2:41 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Steven Rostedt, Frederic Weisbecker, Linux Kernel Mailing List,
Peter Zijlstra, Ingo Molnar
CC: Peter, Ingo
> Hey alright 2.6.31-rc6 booted.
>
> I must admit, I've been afraid of doing
> a git bisect for some time now. but after learning
> to do a bisect, I cant see a better solution to finding a
> bug(biggest issue I see is having a huge .config).
>
> Anyways the culprit for my issue is this commit:
>
> af6af30c0fcd77e621638e53ef8b176bca8bd3b4
>
> reverting this on rc6 booted the machine up.
>
Thanks!
Hmm...I don't see how this commit can cause oops:
> @@ -119,11 +119,9 @@ struct ftrace_event_call {
> void *filter;
> void *mod;
>
> -#ifdef CONFIG_EVENT_PROFILE
> - atomic_t profile_count;
> - int (*profile_enable)(struct ftrace_event_call *);
> - void (*profile_disable)(struct ftrace_event_call *);
> -#endif
> + atomic_t profile_count;
> + int (*profile_enable)(struct ftrace_event_call *);
> + void (*profile_disable)(struct ftrace_event_call *);
In your .config, CONFIG_EVENT_PROFILE=y, so this change makes
no difference.
> };
>
> #define MAX_FILTER_PRED 32
> diff --git a/kernel/trace/trace_event_profile.c b/kernel/trace/trace_event_profil
> index 5b5895a..11ba5bb 100644
> --- a/kernel/trace/trace_event_profile.c
> +++ b/kernel/trace/trace_event_profile.c
> @@ -14,7 +14,7 @@ int ftrace_profile_enable(int event_id)
>
> mutex_lock(&event_mutex);
> list_for_each_entry(event, &ftrace_events, list) {
> - if (event->id == event_id) {
> + if (event->id == event_id && event->profile_enable) {
You will run into this hunk only when you run the perf tool,
so should have nothing to do with the boot failure.
> ret = event->profile_enable(event);
> break;
> }
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 23d2972..e75276a 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
> entry = trace_create_file("enable", 0644, call->dir, call,
> enable);
>
> - if (call->id)
> + if (call->id && call->profile_enable)
We do an extra check on ->profile_enable, shouldn't cause bug..
> entry = trace_create_file("id", 0444, call->dir, call,
> id);
Any way, I don't think this commit does the right thing:
- If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
except events/ftrace/<event>/id.
- if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
I think it's better to skip ftrace/ dir in perf tool code, instead of
skipping creating id files in ftrace code.
can you try this patch:
---
include/linux/ftrace_event.h | 2 ++
kernel/trace/trace_events.c | 2 +-
tools/perf/util/parse-events.c | 8 +++++++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a81170d..398c925 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -121,9 +121,11 @@ struct ftrace_event_call {
void *filter;
void *mod;
+#ifdef CONFIG_EVENT_PROFILE
atomic_t profile_count;
int (*profile_enable)(struct ftrace_event_call *);
void (*profile_disable)(struct ftrace_event_call *);
+#endif
};
#define MAX_FILTER_PRED 32
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index e75276a..23d2972 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentry *d_events,
entry = trace_create_file("enable", 0644, call->dir, call,
enable);
- if (call->id && call->profile_enable)
+ if (call->id)
entry = trace_create_file("id", 0444, call->dir, call,
id);
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 0441784..1077ebd 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -113,13 +113,19 @@ static unsigned long hw_cache_stat[C(MAX)] = {
[C(BPU)] = (CACHE_READ),
};
+static int is_tp_subsystem(struct dirent *sys_dir)
+{
+ return !!strcmp(sys_dir->d_name, "ftrace");
+}
+
#define for_each_subsystem(sys_dir, sys_dirent, sys_next, file, st) \
while (!readdir_r(sys_dir, &sys_dirent, &sys_next) && sys_next) \
if (snprintf(file, MAXPATHLEN, "%s/%s", debugfs_path, \
sys_dirent.d_name) && \
(!stat(file, &st)) && (S_ISDIR(st.st_mode)) && \
(strcmp(sys_dirent.d_name, ".")) && \
- (strcmp(sys_dirent.d_name, "..")))
+ (strcmp(sys_dirent.d_name, "..")) && \
+ (is_tp_subsystem(&sys_dirent)))
static int tp_event_has_id(struct dirent *sys_dir, struct dirent *evt_dir)
{
^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 2:41 ` Li Zefan
@ 2009-08-24 3:07 ` Justin P. Mattock
2009-08-24 5:58 ` Peter Zijlstra
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-24 3:07 UTC (permalink / raw)
To: Li Zefan
Cc: Steven Rostedt, Frederic Weisbecker, Linux Kernel Mailing List,
Peter Zijlstra, Ingo Molnar
Li Zefan wrote:
> CC: Peter, Ingo
>
>
>> Hey alright 2.6.31-rc6 booted.
>>
>> I must admit, I've been afraid of doing
>> a git bisect for some time now. but after learning
>> to do a bisect, I cant see a better solution to finding a
>> bug(biggest issue I see is having a huge .config).
>>
>> Anyways the culprit for my issue is this commit:
>>
>> af6af30c0fcd77e621638e53ef8b176bca8bd3b4
>>
>> reverting this on rc6 booted the machine up.
>>
>>
>
> Thanks!
>
> Hmm...I don't see how this commit can cause oops:
>
same here, perf is not enabled at all.
before the git bisect I manually reverted all perf
and came to the conclusion the perf had nothing to do with this.
(must have missed this commit).
>
>> @@ -119,11 +119,9 @@ struct ftrace_event_call {
>> void *filter;
>> void *mod;
>>
>> -#ifdef CONFIG_EVENT_PROFILE
>> - atomic_t profile_count;
>> - int (*profile_enable)(struct ftrace_event_call *);
>> - void (*profile_disable)(struct ftrace_event_call *);
>> -#endif
>> + atomic_t profile_count;
>> + int (*profile_enable)(struct ftrace_event_call *);
>> + void (*profile_disable)(struct ftrace_event_call *);
>>
>
> In your .config, CONFIG_EVENT_PROFILE=y, so this change makes
> no difference.
>
>
>> };
>>
>> #define MAX_FILTER_PRED 32
>> diff --git a/kernel/trace/trace_event_profile.c b/kernel/trace/trace_event_profil
>> index 5b5895a..11ba5bb 100644
>> --- a/kernel/trace/trace_event_profile.c
>> +++ b/kernel/trace/trace_event_profile.c
>> @@ -14,7 +14,7 @@ int ftrace_profile_enable(int event_id)
>>
>> mutex_lock(&event_mutex);
>> list_for_each_entry(event,&ftrace_events, list) {
>> - if (event->id == event_id) {
>> + if (event->id == event_id&& event->profile_enable) {
>>
>
> You will run into this hunk only when you run the perf tool,
> so should have nothing to do with the boot failure.
>
I haven't really looked into perf yet, nor have it enabled.
>
>> ret = event->profile_enable(event);
>> break;
>> }
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index 23d2972..e75276a 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>> entry = trace_create_file("enable", 0644, call->dir, call,
>> enable);
>>
>> - if (call->id)
>> + if (call->id&& call->profile_enable)
>>
>
> We do an extra check on ->profile_enable, shouldn't cause bug..
>
maybe this has something to do with SELinux, since I saw with
the oops something with inode_do_init_dentry, and some other stuff
pertaining to SELinux(again though I'm lost as to why I'm hitting this).
>
>> entry = trace_create_file("id", 0444, call->dir, call,
>> id);
>>
>
> Any way, I don't think this commit does the right thing:
>
> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
> except events/ftrace/<event>/id.
>
> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>
> I think it's better to skip ftrace/ dir in perf tool code, instead of
> skipping creating id files in ftrace code.
>
> can you try this patch:
>
> ---
> include/linux/ftrace_event.h | 2 ++
> kernel/trace/trace_events.c | 2 +-
> tools/perf/util/parse-events.c | 8 +++++++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index a81170d..398c925 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -121,9 +121,11 @@ struct ftrace_event_call {
> void *filter;
> void *mod;
>
> +#ifdef CONFIG_EVENT_PROFILE
> atomic_t profile_count;
> int (*profile_enable)(struct ftrace_event_call *);
> void (*profile_disable)(struct ftrace_event_call *);
> +#endif
> };
>
> #define MAX_FILTER_PRED 32
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index e75276a..23d2972 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentry *d_events,
> entry = trace_create_file("enable", 0644, call->dir, call,
> enable);
>
> - if (call->id&& call->profile_enable)
> + if (call->id)
> entry = trace_create_file("id", 0444, call->dir, call,
> id);
>
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 0441784..1077ebd 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -113,13 +113,19 @@ static unsigned long hw_cache_stat[C(MAX)] = {
> [C(BPU)] = (CACHE_READ),
> };
>
> +static int is_tp_subsystem(struct dirent *sys_dir)
> +{
> + return !!strcmp(sys_dir->d_name, "ftrace");
> +}
> +
> #define for_each_subsystem(sys_dir, sys_dirent, sys_next, file, st) \
> while (!readdir_r(sys_dir,&sys_dirent,&sys_next)&& sys_next) \
> if (snprintf(file, MAXPATHLEN, "%s/%s", debugfs_path, \
> sys_dirent.d_name)&& \
> (!stat(file,&st))&& (S_ISDIR(st.st_mode))&& \
> (strcmp(sys_dirent.d_name, "."))&& \
> - (strcmp(sys_dirent.d_name, "..")))
> + (strcmp(sys_dirent.d_name, ".."))&& \
> + (is_tp_subsystem(&sys_dirent)))
>
> static int tp_event_has_id(struct dirent *sys_dir, struct dirent *evt_dir)
> {
>
>
>
>
Alright, in the morning I try this out and let you
know what happens.
Thanks for looking at this.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 2:41 ` Li Zefan
2009-08-24 3:07 ` Justin P. Mattock
@ 2009-08-24 5:58 ` Peter Zijlstra
2009-08-24 6:13 ` Li Zefan
1 sibling, 1 reply; 62+ messages in thread
From: Peter Zijlstra @ 2009-08-24 5:58 UTC (permalink / raw)
To: Li Zefan
Cc: Justin P. Mattock, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
> > @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
> > entry = trace_create_file("enable", 0644, call->dir, call,
> > enable);
> >
> > - if (call->id)
> > + if (call->id && call->profile_enable)
>
> We do an extra check on ->profile_enable, shouldn't cause bug..
>
> > entry = trace_create_file("id", 0444, call->dir, call,
> > id);
>
> Any way, I don't think this commit does the right thing:
>
> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
> except events/ftrace/<event>/id.
>
> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>
> I think it's better to skip ftrace/ dir in perf tool code, instead of
> skipping creating id files in ftrace code.
No, it does do the right thing. Your patch breaks things because not all
tracepoints are created through TRACE_EVENT() and will thus not have
their profile_enable/disable hooks set.
By giving them an ID file, there is no way to distinguish good from bad
tracepoints.
Expempting ftrace is no solid solution, suppose someone else does a
TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
a profile event source?
The id files really must stay conditional.
Aside from that, you only add #ifdef fuzz back which with his config is
moot, and shouldn't result in anything but a slightly bigger structure
to begin with.
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 5:58 ` Peter Zijlstra
@ 2009-08-24 6:13 ` Li Zefan
2009-08-24 6:49 ` Justin P. Mattock
2009-08-24 6:55 ` Peter Zijlstra
0 siblings, 2 replies; 62+ messages in thread
From: Li Zefan @ 2009-08-24 6:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Justin P. Mattock, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
Peter Zijlstra wrote:
> On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
>
>>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>>> entry = trace_create_file("enable", 0644, call->dir, call,
>>> enable);
>>>
>>> - if (call->id)
>>> + if (call->id && call->profile_enable)
>> We do an extra check on ->profile_enable, shouldn't cause bug..
>>
>>> entry = trace_create_file("id", 0444, call->dir, call,
>>> id);
>> Any way, I don't think this commit does the right thing:
>>
>> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
>> except events/ftrace/<event>/id.
>>
>> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>>
>> I think it's better to skip ftrace/ dir in perf tool code, instead of
>> skipping creating id files in ftrace code.
>
> No, it does do the right thing. Your patch breaks things because not all
> tracepoints are created through TRACE_EVENT() and will thus not have
> their profile_enable/disable hooks set.
>
> By giving them an ID file, there is no way to distinguish good from bad
> tracepoints.
>
But removing the id file from events/ftrace/ might break some ftrace
binary parsers?
And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
> Expempting ftrace is no solid solution, suppose someone else does a
> TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
> a profile event source?
>
Agree.
> The id files really must stay conditional.
>
I don't think it's a good idea to connect it with perfcounter
this way. Wouldn't adding a 'profilable' file more intuitive?
> Aside from that, you only add #ifdef fuzz back which with his config is
> moot, and shouldn't result in anything but a slightly bigger structure
> to begin with.
>
Yeah, actually I still fail to see where the bug is, maybe
the commit that Justin bisected down is not the real culprit..
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 6:13 ` Li Zefan
@ 2009-08-24 6:49 ` Justin P. Mattock
2009-08-24 6:55 ` Peter Zijlstra
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-24 6:49 UTC (permalink / raw)
To: Li Zefan
Cc: Peter Zijlstra, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
Li Zefan wrote:
> Peter Zijlstra wrote:
>
>> On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
>>
>>
>>>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>>>> entry = trace_create_file("enable", 0644, call->dir, call,
>>>> enable);
>>>>
>>>> - if (call->id)
>>>> + if (call->id&& call->profile_enable)
>>>>
>>> We do an extra check on ->profile_enable, shouldn't cause bug..
>>>
>>>
>>>> entry = trace_create_file("id", 0444, call->dir, call,
>>>> id);
>>>>
>>> Any way, I don't think this commit does the right thing:
>>>
>>> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
>>> except events/ftrace/<event>/id.
>>>
>>> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>>>
>>> I think it's better to skip ftrace/ dir in perf tool code, instead of
>>> skipping creating id files in ftrace code.
>>>
>> No, it does do the right thing. Your patch breaks things because not all
>> tracepoints are created through TRACE_EVENT() and will thus not have
>> their profile_enable/disable hooks set.
>>
>> By giving them an ID file, there is no way to distinguish good from bad
>> tracepoints.
>>
>>
>
> But removing the id file from events/ftrace/ might break some ftrace
> binary parsers?
>
> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
>
>
>> Expempting ftrace is no solid solution, suppose someone else does a
>> TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
>> a profile event source?
>>
>>
>
> Agree.
>
>
>> The id files really must stay conditional.
>>
>>
>
> I don't think it's a good idea to connect it with perfcounter
> this way. Wouldn't adding a 'profilable' file more intuitive?
>
>
>> Aside from that, you only add #ifdef fuzz back which with his config is
>> moot, and shouldn't result in anything but a slightly bigger structure
>> to begin with.
>>
>>
>
> Yeah, actually I still fail to see where the bug is, maybe
> the commit that Justin bisected down is not the real culprit..
>
>
>
FWIW, here is the git bisect log:
git bisect start
# bad: [6c30c53fd5ae6a99a23ad78e90c428d2c8ffb07f] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2
git bisect bad 6c30c53fd5ae6a99a23ad78e90c428d2c8ffb07f
# good: [b600ffaebcc4791add19e04306f0478a963abe71] Merge branch
'irq-fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good b600ffaebcc4791add19e04306f0478a963abe71
# good: [ae83060026537885fd23737af161fee8afd04f4b] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good ae83060026537885fd23737af161fee8afd04f4b
# bad: [b637dc0dba6a243da2c74f5d02b42ba5eeb9425e] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
git bisect bad b637dc0dba6a243da2c74f5d02b42ba5eeb9425e
# bad: [cf7fdd57f978d40ceb9a0f58a25f5cf9c84d6f33] USB: fix oops on
disconnect in cdc-acm
git bisect bad cf7fdd57f978d40ceb9a0f58a25f5cf9c84d6f33
# good: [131f7340b4f93f9a4a8e5a65abbd352b34d0ee08] Merge branch
'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect good 131f7340b4f93f9a4a8e5a65abbd352b34d0ee08
# good: [c0c60c4b9ab45bb02b20796401dd6a90770fd0ee] ARM: 5639/1: arm:
clkdev.c should include <linux/clk.h>
git bisect good c0c60c4b9ab45bb02b20796401dd6a90770fd0ee
# bad: [da758ddede96dd850945d3417ff75209a666ba0d] Merge branch
'perfcounters-fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad da758ddede96dd850945d3417ff75209a666ba0d
# good: [389623fef0e8b088f293c437d3b7094fe82349fd] Merge
git://git.infradead.org/mtd-2.6
git bisect good 389623fef0e8b088f293c437d3b7094fe82349fd
# bad: [af6af30c0fcd77e621638e53ef8b176bca8bd3b4] ftrace: Fix
perf-tracepoint OOPS
git bisect bad af6af30c0fcd77e621638e53ef8b176bca8bd3b4
# good: [2cdbc46d7b2cb0acb68c3ecad93b000552121fa6] perf: Auto-detect libbfd
git bisect good 2cdbc46d7b2cb0acb68c3ecad93b000552121fa6
# good: [386c0b702b1ea81c0f54f5c9832a3d4a52270f14] perf report: Add
missing command line options to man page
git bisect good 386c0b702b1ea81c0f54f5c9832a3d4a52270f14
all I know is with 2.6.31-rc5 booted fine, as soon I loaded 2.6.31-rc6
I hit this stuckage(I can write it manually down if you need it,
seems ohci1394_dma gets a panic).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 6:13 ` Li Zefan
2009-08-24 6:49 ` Justin P. Mattock
@ 2009-08-24 6:55 ` Peter Zijlstra
2009-08-24 7:54 ` Justin P. Mattock
2009-08-24 8:40 ` Justin P. Mattock
1 sibling, 2 replies; 62+ messages in thread
From: Peter Zijlstra @ 2009-08-24 6:55 UTC (permalink / raw)
To: Li Zefan
Cc: Justin P. Mattock, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
On Mon, 2009-08-24 at 14:13 +0800, Li Zefan wrote:
> Peter Zijlstra wrote:
> > On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
> >
> >>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
> >>> entry = trace_create_file("enable", 0644, call->dir, call,
> >>> enable);
> >>>
> >>> - if (call->id)
> >>> + if (call->id && call->profile_enable)
> >> We do an extra check on ->profile_enable, shouldn't cause bug..
> >>
> >>> entry = trace_create_file("id", 0444, call->dir, call,
> >>> id);
> >> Any way, I don't think this commit does the right thing:
> >>
> >> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
> >> except events/ftrace/<event>/id.
> >>
> >> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
> >>
> >> I think it's better to skip ftrace/ dir in perf tool code, instead of
> >> skipping creating id files in ftrace code.
> >
> > No, it does do the right thing. Your patch breaks things because not all
> > tracepoints are created through TRACE_EVENT() and will thus not have
> > their profile_enable/disable hooks set.
> >
> > By giving them an ID file, there is no way to distinguish good from bad
> > tracepoints.
> >
>
> But removing the id file from events/ftrace/ might break some ftrace
> binary parsers?
>
> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
I introduced the id file for EVENT_PROFILE, tough luck if someone else
relies on it.
> > Expempting ftrace is no solid solution, suppose someone else does a
> > TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
> > a profile event source?
> >
>
> Agree.
>
> > The id files really must stay conditional.
> >
>
> I don't think it's a good idea to connect it with perfcounter
> this way. Wouldn't adding a 'profilable' file more intuitive?
its called: id ;-)
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 6:55 ` Peter Zijlstra
@ 2009-08-24 7:54 ` Justin P. Mattock
2009-08-24 8:40 ` Justin P. Mattock
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-24 7:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
Peter Zijlstra wrote:
> On Mon, 2009-08-24 at 14:13 +0800, Li Zefan wrote:
>
>> Peter Zijlstra wrote:
>>
>>> On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
>>>
>>>
>>>>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>>>>> entry = trace_create_file("enable", 0644, call->dir, call,
>>>>> enable);
>>>>>
>>>>> - if (call->id)
>>>>> + if (call->id&& call->profile_enable)
>>>>>
>>>> We do an extra check on ->profile_enable, shouldn't cause bug..
>>>>
>>>>
>>>>> entry = trace_create_file("id", 0444, call->dir, call,
>>>>> id);
>>>>>
>>>> Any way, I don't think this commit does the right thing:
>>>>
>>>> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
>>>> except events/ftrace/<event>/id.
>>>>
>>>> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>>>>
>>>> I think it's better to skip ftrace/ dir in perf tool code, instead of
>>>> skipping creating id files in ftrace code.
>>>>
>>> No, it does do the right thing. Your patch breaks things because not all
>>> tracepoints are created through TRACE_EVENT() and will thus not have
>>> their profile_enable/disable hooks set.
>>>
>>> By giving them an ID file, there is no way to distinguish good from bad
>>> tracepoints.
>>>
>>>
>> But removing the id file from events/ftrace/ might break some ftrace
>> binary parsers?
>>
>> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
>>
>
> I introduced the id file for EVENT_PROFILE, tough luck if someone else
> relies on it.
>
>
>>> Expempting ftrace is no solid solution, suppose someone else does a
>>> TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
>>> a profile event source?
>>>
>>>
>> Agree.
>>
>>
>>> The id files really must stay conditional.
>>>
>>>
>> I don't think it's a good idea to connect it with perfcounter
>> this way. Wouldn't adding a 'profilable' file more intuitive?
>>
>
> its called: id ;-)
>
>
Alright, I'm going to go back to the beginning
and start my build from scratch(make sure things are legit).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 6:55 ` Peter Zijlstra
2009-08-24 7:54 ` Justin P. Mattock
@ 2009-08-24 8:40 ` Justin P. Mattock
2009-08-24 19:19 ` Justin Mattock
1 sibling, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-24 8:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
Peter Zijlstra wrote:
> On Mon, 2009-08-24 at 14:13 +0800, Li Zefan wrote:
>
>> Peter Zijlstra wrote:
>>
>>> On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
>>>
>>>
>>>>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>>>>> entry = trace_create_file("enable", 0644, call->dir, call,
>>>>> enable);
>>>>>
>>>>> - if (call->id)
>>>>> + if (call->id&& call->profile_enable)
>>>>>
>>>> We do an extra check on ->profile_enable, shouldn't cause bug..
>>>>
>>>>
>>>>> entry = trace_create_file("id", 0444, call->dir, call,
>>>>> id);
>>>>>
>>>> Any way, I don't think this commit does the right thing:
>>>>
>>>> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
>>>> except events/ftrace/<event>/id.
>>>>
>>>> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>>>>
>>>> I think it's better to skip ftrace/ dir in perf tool code, instead of
>>>> skipping creating id files in ftrace code.
>>>>
>>> No, it does do the right thing. Your patch breaks things because not all
>>> tracepoints are created through TRACE_EVENT() and will thus not have
>>> their profile_enable/disable hooks set.
>>>
>>> By giving them an ID file, there is no way to distinguish good from bad
>>> tracepoints.
>>>
>>>
>> But removing the id file from events/ftrace/ might break some ftrace
>> binary parsers?
>>
>> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
>>
>
> I introduced the id file for EVENT_PROFILE, tough luck if someone else
> relies on it.
>
>
>>> Expempting ftrace is no solid solution, suppose someone else does a
>>> TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
>>> a profile event source?
>>>
>>>
>> Agree.
>>
>>
>>> The id files really must stay conditional.
>>>
>>>
>> I don't think it's a good idea to connect it with perfcounter
>> this way. Wouldn't adding a 'profilable' file more intuitive?
>>
>
> its called: id ;-)
>
>
After looking at ps auxZ
I see xterm as root instead of my user name.
This gives me enough evidence to throw
this system away and start over.
sorry for the waste of time.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 8:40 ` Justin P. Mattock
@ 2009-08-24 19:19 ` Justin Mattock
2009-08-25 5:50 ` Peter Zijlstra
2009-08-25 8:59 ` Ingo Molnar
0 siblings, 2 replies; 62+ messages in thread
From: Justin Mattock @ 2009-08-24 19:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
On Mon, Aug 24, 2009 at 1:40 AM, Justin P.
Mattock<justinmattock@gmail.com> wrote:
> Peter Zijlstra wrote:
>>
>> On Mon, 2009-08-24 at 14:13 +0800, Li Zefan wrote:
>>
>>>
>>> Peter Zijlstra wrote:
>>>
>>>>
>>>> On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
>>>>
>>>>
>>>>>>
>>>>>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call,
>>>>>> struct dentr
>>>>>> entry = trace_create_file("enable", 0644, call->dir,
>>>>>> call,
>>>>>> enable);
>>>>>>
>>>>>> - if (call->id)
>>>>>> + if (call->id&& call->profile_enable)
>>>>>>
>>>>>
>>>>> We do an extra check on ->profile_enable, shouldn't cause bug..
>>>>>
>>>>>
>>>>>>
>>>>>> entry = trace_create_file("id", 0444, call->dir, call,
>>>>>> id);
>>>>>>
>>>>>
>>>>> Any way, I don't think this commit does the right thing:
>>>>>
>>>>> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
>>>>> except events/ftrace/<event>/id.
>>>>>
>>>>> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>>>>>
>>>>> I think it's better to skip ftrace/ dir in perf tool code, instead of
>>>>> skipping creating id files in ftrace code.
>>>>>
>>>>
>>>> No, it does do the right thing. Your patch breaks things because not all
>>>> tracepoints are created through TRACE_EVENT() and will thus not have
>>>> their profile_enable/disable hooks set.
>>>>
>>>> By giving them an ID file, there is no way to distinguish good from bad
>>>> tracepoints.
>>>>
>>>>
>>>
>>> But removing the id file from events/ftrace/ might break some ftrace
>>> binary parsers?
>>>
>>> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
>>>
>>
>> I introduced the id file for EVENT_PROFILE, tough luck if someone else
>> relies on it.
>>
>>
>>>>
>>>> Expempting ftrace is no solid solution, suppose someone else does a
>>>> TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
>>>> a profile event source?
>>>>
>>>>
>>>
>>> Agree.
>>>
>>>
>>>>
>>>> The id files really must stay conditional.
>>>>
>>>>
>>>
>>> I don't think it's a good idea to connect it with perfcounter
>>> this way. Wouldn't adding a 'profilable' file more intuitive?
>>>
>>
>> its called: id ;-)
>>
>>
>
> After looking at ps auxZ
> I see xterm as root instead of my user name.
> This gives me enough evidence to throw
> this system away and start over.
>
> sorry for the waste of time.
>
> Justin P. Mattock
>
O.K. I feel better, deleted
my system, and threw in a minimal built system
with only the bare essentials to boot.
(just to make sure things are correct).
unfortunately after building rc6 I'm still hitting
this. really am not sure why this is happening.
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-22 7:48 ` Justin P. Mattock
2009-08-24 2:41 ` Li Zefan
@ 2009-08-24 19:42 ` Steven Rostedt
2009-08-24 23:34 ` Justin Mattock
1 sibling, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-08-24 19:42 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
On Sat, 22 Aug 2009, Justin P. Mattock wrote:
> I must admit, I've been afraid of doing
> a git bisect for some time now. but after learning
> to do a bisect, I cant see a better solution to finding a
> bug(biggest issue I see is having a huge .config).
http://rostedt.homelinux.com/code/streamline_config.pl
It will remove any module from your config that is not loaded. Makes
compiling kernels much faster.
(also featured in LWN this week: http://lwn.net/Articles/347713/)
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 19:42 ` Steven Rostedt
@ 2009-08-24 23:34 ` Justin Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin Mattock @ 2009-08-24 23:34 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
On Mon, Aug 24, 2009 at 12:42 PM, Steven Rostedt<rostedt@goodmis.org> wrote:
>
> On Sat, 22 Aug 2009, Justin P. Mattock wrote:
>> I must admit, I've been afraid of doing
>> a git bisect for some time now. but after learning
>> to do a bisect, I cant see a better solution to finding a
>> bug(biggest issue I see is having a huge .config).
>
> http://rostedt.homelinux.com/code/streamline_config.pl
ahh noway!! finally a nice and small .config
Ill try it out.
>
> It will remove any module from your config that is not loaded. Makes
> compiling kernels much faster.
>
> (also featured in LWN this week: http://lwn.net/Articles/347713/)
>
> -- Steve
>
>
Ill have to look at that feature.
(need to register).
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 19:19 ` Justin Mattock
@ 2009-08-25 5:50 ` Peter Zijlstra
2009-08-25 6:04 ` Li Zefan
2009-08-25 8:59 ` Ingo Molnar
1 sibling, 1 reply; 62+ messages in thread
From: Peter Zijlstra @ 2009-08-25 5:50 UTC (permalink / raw)
To: Justin Mattock
Cc: Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
On Mon, 2009-08-24 at 12:19 -0700, Justin Mattock wrote:
> O.K. I feel better, deleted
> my system, and threw in a minimal built system
> with only the bare essentials to boot.
> (just to make sure things are correct).
>
> unfortunately after building rc6 I'm still hitting
> this. really am not sure why this is happening.
Could you share your .config so we could have a try?
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-25 5:50 ` Peter Zijlstra
@ 2009-08-25 6:04 ` Li Zefan
2009-08-25 6:21 ` Peter Zijlstra
0 siblings, 1 reply; 62+ messages in thread
From: Li Zefan @ 2009-08-25 6:04 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Justin Mattock, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
Peter Zijlstra wrote:
> On Mon, 2009-08-24 at 12:19 -0700, Justin Mattock wrote:
>
>> O.K. I feel better, deleted
>> my system, and threw in a minimal built system
>> with only the bare essentials to boot.
>> (just to make sure things are correct).
>>
>> unfortunately after building rc6 I'm still hitting
>> this. really am not sure why this is happening.
>
> Could you share your .config so we could have a try?
>
Justin sent his config in an earlier mail in this thread.
But Steven didn't reproduce the bug with the config,
neither me.
And we don't receive another bug report regarding to this
crash.
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-25 6:04 ` Li Zefan
@ 2009-08-25 6:21 ` Peter Zijlstra
0 siblings, 0 replies; 62+ messages in thread
From: Peter Zijlstra @ 2009-08-25 6:21 UTC (permalink / raw)
To: Li Zefan
Cc: Justin Mattock, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List, Ingo Molnar
On Tue, 2009-08-25 at 14:04 +0800, Li Zefan wrote:
> Peter Zijlstra wrote:
> > On Mon, 2009-08-24 at 12:19 -0700, Justin Mattock wrote:
> >
> >> O.K. I feel better, deleted
> >> my system, and threw in a minimal built system
> >> with only the bare essentials to boot.
> >> (just to make sure things are correct).
> >>
> >> unfortunately after building rc6 I'm still hitting
> >> this. really am not sure why this is happening.
> >
> > Could you share your .config so we could have a try?
> >
>
> Justin sent his config in an earlier mail in this thread.
> But Steven didn't reproduce the bug with the config,
> neither me.
>
> And we don't receive another bug report regarding to this
> crash.
Right, weird story this..
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-24 19:19 ` Justin Mattock
2009-08-25 5:50 ` Peter Zijlstra
@ 2009-08-25 8:59 ` Ingo Molnar
2009-08-26 0:22 ` Justin P. Mattock
1 sibling, 1 reply; 62+ messages in thread
From: Ingo Molnar @ 2009-08-25 8:59 UTC (permalink / raw)
To: Justin Mattock
Cc: Peter Zijlstra, Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List
* Justin Mattock <justinmattock@gmail.com> wrote:
> O.K. I feel better, deleted
> my system, and threw in a minimal built system
> with only the bare essentials to boot.
> (just to make sure things are correct).
>
> unfortunately after building rc6 I'm still hitting
> this. really am not sure why this is happening.
Could you please double-check the bisection result by doing this:
git revert af6af30c0f
on the latest kernel and seeing whether that fixes the lockup?
Bisections are very efficient and hence very sensitive as well to
minimal errors. Just one small mistake near the end of a bisection
can blame the wrong commit.
So the best way to double-check such 100%-triggerable crashes is to
do the revert. I tried the revert and it can be done fine here.
[ _If_ that does not fix the bug then to save time you can
'backtrack' the bisection, instead of re-doing it completely.
I.e. you have your bisection log, re-check the final steps going
backwards. Once you find a discrepancy (i.e. a 'bad' point that
is 'good' or the other way around), redo the bisection log
commands up to that point and continue it up to the end. ]
Ingo
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-25 8:59 ` Ingo Molnar
@ 2009-08-26 0:22 ` Justin P. Mattock
2009-08-26 7:33 ` Ingo Molnar
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-26 0:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List
Ingo Molnar wrote:
> * Justin Mattock<justinmattock@gmail.com> wrote:
>
>
>> O.K. I feel better, deleted
>> my system, and threw in a minimal built system
>> with only the bare essentials to boot.
>> (just to make sure things are correct).
>>
>> unfortunately after building rc6 I'm still hitting
>> this. really am not sure why this is happening.
>>
>
> Could you please double-check the bisection result by doing this:
>
> git revert af6af30c0f
>
> on the latest kernel and seeing whether that fixes the lockup?
>
> Bisections are very efficient and hence very sensitive as well to
> minimal errors. Just one small mistake near the end of a bisection
> can blame the wrong commit.
>
> So the best way to double-check such 100%-triggerable crashes is to
> do the revert. I tried the revert and it can be done fine here.
>
> [ _If_ that does not fix the bug then to save time you can
> 'backtrack' the bisection, instead of re-doing it completely.
> I.e. you have your bisection log, re-check the final steps going
> backwards. Once you find a discrepancy (i.e. a 'bad' point that
> is 'good' or the other way around), redo the bisection log
> commands up to that point and continue it up to the end. ]
>
> Ingo
>
>
shoot, I did not see your post here.
when looking at my bisect log, I guess after a
git bisect reset it clears?
Anyways after git bisect had finished
I looked manually at the commits that it
had generated
the one which I had sent in a post previously, and
this one:
9424edc2da097c8589fcc24a72552d33e54be161
at the time looking at the commit, I see this to be
more of the cause because of it being related to elf as so forth,
but as soon as I reverted this on rc6
made no difference.(the previous commit fixes this for
me, on a regular tar.ball as well as in git.
I think at this point since this system is a fresh from scratch
build, I think something might be wrong that I'm doing
(all the CFLAGS, and such are in a previous post).
At the moment I don't have a problem applying a patch
to the kernel for this. especially since I'm the only one that seems
to be hitting this, then if more and more reports of this happen
then we can go from there.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-26 0:22 ` Justin P. Mattock
@ 2009-08-26 7:33 ` Ingo Molnar
2009-08-26 14:42 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Ingo Molnar @ 2009-08-26 7:33 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Peter Zijlstra, Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List
* Justin P. Mattock <justinmattock@gmail.com> wrote:
> Ingo Molnar wrote:
>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>
>>
>>> O.K. I feel better, deleted
>>> my system, and threw in a minimal built system
>>> with only the bare essentials to boot.
>>> (just to make sure things are correct).
>>>
>>> unfortunately after building rc6 I'm still hitting
>>> this. really am not sure why this is happening.
>>>
>>
>> Could you please double-check the bisection result by doing this:
>>
>> git revert af6af30c0f
>>
>> on the latest kernel and seeing whether that fixes the lockup?
>>
>> Bisections are very efficient and hence very sensitive as well to
>> minimal errors. Just one small mistake near the end of a bisection
>> can blame the wrong commit.
>>
>> So the best way to double-check such 100%-triggerable crashes is to
>> do the revert. I tried the revert and it can be done fine here.
>>
>> [ _If_ that does not fix the bug then to save time you can
>> 'backtrack' the bisection, instead of re-doing it completely.
>> I.e. you have your bisection log, re-check the final steps going
>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>> is 'good' or the other way around), redo the bisection log
>> commands up to that point and continue it up to the end. ]
>>
>> Ingo
>>
>>
> shoot, I did not see your post here. when looking at my bisect
> log, I guess after a git bisect reset it clears?
>
> Anyways after git bisect had finished I looked manually at the
> commits that it had generated the one which I had sent in a post
> previously, and this one:
>
> 9424edc2da097c8589fcc24a72552d33e54be161
(this commit has no effect on your kernel image, at all.)
> at the time looking at the commit, I see this to be more of the
> cause because of it being related to elf as so forth, but as soon
> as I reverted this on rc6 made no difference.(the previous commit
> fixes this for me, on a regular tar.ball as well as in git.
>
> I think at this point since this system is a fresh from scratch
> build, I think something might be wrong that I'm doing (all the
> CFLAGS, and such are in a previous post).
>
> At the moment I don't have a problem applying a patch to the
> kernel for this. especially since I'm the only one that seems to
> be hitting this, then if more and more reports of this happen then
> we can go from there.
What would be nice is to verify your bisection end result, i.e. do
what i suggested:
>> Could you please double-check the bisection result by doing this:
>>
>> git revert af6af30c0f
>>
>> on the latest kernel and seeing whether that fixes the lockup?
if this doesnt fix it on latest -git then this commit is not the
cause of the lockup.
Ingo
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-26 7:33 ` Ingo Molnar
@ 2009-08-26 14:42 ` Justin P. Mattock
2009-09-07 21:49 ` Justin Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-08-26 14:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List
Ingo Molnar wrote:
> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>
>
>> Ingo Molnar wrote:
>>
>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>>
>>>
>>>
>>>> O.K. I feel better, deleted
>>>> my system, and threw in a minimal built system
>>>> with only the bare essentials to boot.
>>>> (just to make sure things are correct).
>>>>
>>>> unfortunately after building rc6 I'm still hitting
>>>> this. really am not sure why this is happening.
>>>>
>>>>
>>> Could you please double-check the bisection result by doing this:
>>>
>>> git revert af6af30c0f
>>>
>>> on the latest kernel and seeing whether that fixes the lockup?
>>>
>>> Bisections are very efficient and hence very sensitive as well to
>>> minimal errors. Just one small mistake near the end of a bisection
>>> can blame the wrong commit.
>>>
>>> So the best way to double-check such 100%-triggerable crashes is to
>>> do the revert. I tried the revert and it can be done fine here.
>>>
>>> [ _If_ that does not fix the bug then to save time you can
>>> 'backtrack' the bisection, instead of re-doing it completely.
>>> I.e. you have your bisection log, re-check the final steps going
>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>>> is 'good' or the other way around), redo the bisection log
>>> commands up to that point and continue it up to the end. ]
>>>
>>> Ingo
>>>
>>>
>>>
>> shoot, I did not see your post here. when looking at my bisect
>> log, I guess after a git bisect reset it clears?
>>
>> Anyways after git bisect had finished I looked manually at the
>> commits that it had generated the one which I had sent in a post
>> previously, and this one:
>>
>> 9424edc2da097c8589fcc24a72552d33e54be161
>>
>
> (this commit has no effect on your kernel image, at all.)
>
>
yep. but it was worth a try.
>> at the time looking at the commit, I see this to be more of the
>> cause because of it being related to elf as so forth, but as soon
>> as I reverted this on rc6 made no difference.(the previous commit
>> fixes this for me, on a regular tar.ball as well as in git.
>>
>> I think at this point since this system is a fresh from scratch
>> build, I think something might be wrong that I'm doing (all the
>> CFLAGS, and such are in a previous post).
>>
>> At the moment I don't have a problem applying a patch to the
>> kernel for this. especially since I'm the only one that seems to
>> be hitting this, then if more and more reports of this happen then
>> we can go from there.
>>
>
> What would be nice is to verify your bisection end result, i.e. do
> what i suggested:
>
>
yeah I've done this on both kernels three to be exact, and all boot
after reverting
Fix perf-tracepoint OOPS.
As for my system, I'm still convinced that I might be doing something
wrong over here.
>>> Could you please double-check the bisection result by doing this:
>>>
>>> git revert af6af30c0f
>>>
>>> on the latest kernel and seeing whether that fixes the lockup?
>>>
>
> if this doesnt fix it on latest -git then this commit is not the
> cause of the lockup.
>
> Ingo
>
>
This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm
left, as well as others asking
the question of why.
In any case I still think I'm setting something wrong with either gcc,
or something
that might be causing this from userland.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-08-26 14:42 ` Justin P. Mattock
@ 2009-09-07 21:49 ` Justin Mattock
2009-10-02 21:12 ` Jason Baron
0 siblings, 1 reply; 62+ messages in thread
From: Justin Mattock @ 2009-09-07 21:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Li Zefan, Steven Rostedt, Frederic Weisbecker,
Linux Kernel Mailing List
On Wed, Aug 26, 2009 at 7:42 AM, Justin P.
Mattock<justinmattock@gmail.com> wrote:
> Ingo Molnar wrote:
>>
>> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>>
>>
>>>
>>> Ingo Molnar wrote:
>>>
>>>>
>>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> O.K. I feel better, deleted
>>>>> my system, and threw in a minimal built system
>>>>> with only the bare essentials to boot.
>>>>> (just to make sure things are correct).
>>>>>
>>>>> unfortunately after building rc6 I'm still hitting
>>>>> this. really am not sure why this is happening.
>>>>>
>>>>>
>>>>
>>>> Could you please double-check the bisection result by doing this:
>>>>
>>>> git revert af6af30c0f
>>>>
>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>
>>>> Bisections are very efficient and hence very sensitive as well to
>>>> minimal errors. Just one small mistake near the end of a bisection
>>>> can blame the wrong commit.
>>>>
>>>> So the best way to double-check such 100%-triggerable crashes is to
>>>> do the revert. I tried the revert and it can be done fine here.
>>>>
>>>> [ _If_ that does not fix the bug then to save time you can
>>>> 'backtrack' the bisection, instead of re-doing it completely.
>>>> I.e. you have your bisection log, re-check the final steps going
>>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>>>> is 'good' or the other way around), redo the bisection log
>>>> commands up to that point and continue it up to the end. ]
>>>>
>>>> Ingo
>>>>
>>>>
>>>>
>>>
>>> shoot, I did not see your post here. when looking at my bisect
>>> log, I guess after a git bisect reset it clears?
>>>
>>> Anyways after git bisect had finished I looked manually at the
>>> commits that it had generated the one which I had sent in a post
>>> previously, and this one:
>>>
>>> 9424edc2da097c8589fcc24a72552d33e54be161
>>>
>>
>> (this commit has no effect on your kernel image, at all.)
>>
>>
>
> yep. but it was worth a try.
>>>
>>> at the time looking at the commit, I see this to be more of the
>>> cause because of it being related to elf as so forth, but as soon
>>> as I reverted this on rc6 made no difference.(the previous commit
>>> fixes this for me, on a regular tar.ball as well as in git.
>>>
>>> I think at this point since this system is a fresh from scratch
>>> build, I think something might be wrong that I'm doing (all the
>>> CFLAGS, and such are in a previous post).
>>>
>>> At the moment I don't have a problem applying a patch to the
>>> kernel for this. especially since I'm the only one that seems to
>>> be hitting this, then if more and more reports of this happen then
>>> we can go from there.
>>>
>>
>> What would be nice is to verify your bisection end result, i.e. do
>> what i suggested:
>>
>>
>
> yeah I've done this on both kernels three to be exact, and all boot after
> reverting
> Fix perf-tracepoint OOPS.
>
> As for my system, I'm still convinced that I might be doing something wrong
> over here.
>
>>>> Could you please double-check the bisection result by doing this:
>>>>
>>>> git revert af6af30c0f
>>>>
>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>
>>
>> if this doesnt fix it on latest -git then this commit is not the
>> cause of the lockup.
>>
>> Ingo
>>
>>
>
> This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
> well as others asking
> the question of why.
> In any case I still think I'm setting something wrong with either gcc, or
> something
> that might be causing this from userland.
>
> Justin P. Mattock
>
O.k. here something awkward about this issue I was
experiencing. at the moment I have two imac's
here the descriptions:
imac A) the one with the problem
OS: built from the clfs book
x86_64 multilib with only lib64
built everything with these flags:
CFLAGS="-m64 -mtune=core2 -march=core2
-mfpmath=both -O2 -pipe -fomit-frame-pointer
-fstack-protection"
CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
while compiling everything with
gcc version: 4.5.0 20090730
imac B) the one that works
OS: clfs(just built a few days ago)
x86_64 pure64 bit build
(lib with a symlink to lib64)
CFLAGS="-m64 -mtune=core2 -march=core2
-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
The only things I can think of is either I hit something
because of gcc, something goes wrong with the libraries,
or there something happening with either the option
of mfpmath=both or stackprotection.
At this point since the kernel seems to be running fine,
is to just trash the system that has this issue and just leave
it at, I was hitting some weird anomaly.
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-09-07 21:49 ` Justin Mattock
@ 2009-10-02 21:12 ` Jason Baron
2009-10-04 17:41 ` Ingo Molnar
2009-10-06 1:24 ` Steven Rostedt
0 siblings, 2 replies; 62+ messages in thread
From: Jason Baron @ 2009-10-02 21:12 UTC (permalink / raw)
To: Justin Mattock
Cc: Ingo Molnar, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
> >>
> >> * Justin P. Mattock<justinmattock@gmail.com> wrote:
> >>
> >>
> >>>
> >>> Ingo Molnar wrote:
> >>>
> >>>>
> >>>> * Justin Mattock<justinmattock@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> O.K. I feel better, deleted
> >>>>> my system, and threw in a minimal built system
> >>>>> with only the bare essentials to boot.
> >>>>> (just to make sure things are correct).
> >>>>>
> >>>>> unfortunately after building rc6 I'm still hitting
> >>>>> this. really am not sure why this is happening.
> >>>>>
> >>>>>
> >>>>
> >>>> Could you please double-check the bisection result by doing this:
> >>>>
> >>>> git revert af6af30c0f
> >>>>
> >>>> on the latest kernel and seeing whether that fixes the lockup?
> >>>>
> >>>> Bisections are very efficient and hence very sensitive as well to
> >>>> minimal errors. Just one small mistake near the end of a bisection
> >>>> can blame the wrong commit.
> >>>>
> >>>> So the best way to double-check such 100%-triggerable crashes is to
> >>>> do the revert. I tried the revert and it can be done fine here.
> >>>>
> >>>> [ _If_ that does not fix the bug then to save time you can
> >>>> 'backtrack' the bisection, instead of re-doing it completely.
> >>>> I.e. you have your bisection log, re-check the final steps going
> >>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
> >>>> is 'good' or the other way around), redo the bisection log
> >>>> commands up to that point and continue it up to the end. ]
> >>>>
> >>>> Ingo
> >>>>
> >>>>
> >>>>
> >>>
> >>> shoot, I did not see your post here. when looking at my bisect
> >>> log, I guess after a git bisect reset it clears?
> >>>
> >>> Anyways after git bisect had finished I looked manually at the
> >>> commits that it had generated the one which I had sent in a post
> >>> previously, and this one:
> >>>
> >>> 9424edc2da097c8589fcc24a72552d33e54be161
> >>>
> >>
> >> (this commit has no effect on your kernel image, at all.)
> >>
> >>
> >
> > yep. but it was worth a try.
> >>>
> >>> at the time looking at the commit, I see this to be more of the
> >>> cause because of it being related to elf as so forth, but as soon
> >>> as I reverted this on rc6 made no difference.(the previous commit
> >>> fixes this for me, on a regular tar.ball as well as in git.
> >>>
> >>> I think at this point since this system is a fresh from scratch
> >>> build, I think something might be wrong that I'm doing (all the
> >>> CFLAGS, and such are in a previous post).
> >>>
> >>> At the moment I don't have a problem applying a patch to the
> >>> kernel for this. especially since I'm the only one that seems to
> >>> be hitting this, then if more and more reports of this happen then
> >>> we can go from there.
> >>>
> >>
> >> What would be nice is to verify your bisection end result, i.e. do
> >> what i suggested:
> >>
> >>
> >
> > yeah I've done this on both kernels three to be exact, and all boot after
> > reverting
> > Fix perf-tracepoint OOPS.
> >
> > As for my system, I'm still convinced that I might be doing something wrong
> > over here.
> >
> >>>> Could you please double-check the bisection result by doing this:
> >>>>
> >>>> git revert af6af30c0f
> >>>>
> >>>> on the latest kernel and seeing whether that fixes the lockup?
> >>>>
> >>
> >> if this doesnt fix it on latest -git then this commit is not the
> >> cause of the lockup.
> >>
> >> Ingo
> >>
> >>
> >
> > This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
> > well as others asking
> > the question of why.
> > In any case I still think I'm setting something wrong with either gcc, or
> > something
> > that might be causing this from userland.
> >
> > Justin P. Mattock
> >
>
> O.k. here something awkward about this issue I was
> experiencing. at the moment I have two imac's
> here the descriptions:
>
> imac A) the one with the problem
>
> OS: built from the clfs book
> x86_64 multilib with only lib64
>
> built everything with these flags:
> CFLAGS="-m64 -mtune=core2 -march=core2
> -mfpmath=both -O2 -pipe -fomit-frame-pointer
> -fstack-protection"
> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
> while compiling everything with
> gcc version: 4.5.0 20090730
>
>
> imac B) the one that works
>
> OS: clfs(just built a few days ago)
> x86_64 pure64 bit build
> (lib with a symlink to lib64)
> CFLAGS="-m64 -mtune=core2 -march=core2
> -O2 -pipe -fomit-frame-pointer"
> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
> gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
>
> The only things I can think of is either I hit something
> because of gcc, something goes wrong with the libraries,
> or there something happening with either the option
> of mfpmath=both or stackprotection.
>
> At this point since the kernel seems to be running fine,
> is to just trash the system that has this issue and just leave
> it at, I was hitting some weird anomaly.
>
hi Justin,
I've been playing around with gcc '4.5' as well and hit a panic that
looks very similar to what you've seen with stock 2.6.31 - I haven't
seen it anywhere else. Anyways, it seems to be some sort of alignment
issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
compiler or kernel issue. But the following kernel patch fixes the issue
for me. It would be interesting to verify if the patch also resolves the
issue for you.
thanks,
-Jason
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6ad76bf..0029af4 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -164,6 +164,7 @@
LIKELY_PROFILE() \
BRANCH_PROFILE() \
TRACE_PRINTKS() \
+ . = ALIGN(32); \
FTRACE_EVENTS() \
TRACE_SYSCALLS()
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a81170d..43f9f1e 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -124,7 +124,7 @@ struct ftrace_event_call {
atomic_t profile_count;
int (*profile_enable)(struct ftrace_event_call *);
void (*profile_disable)(struct ftrace_event_call *);
-};
+} __attribute__((aligned(32)));
#define MAX_FILTER_PRED 32
#define MAX_FILTER_STR_VAL 128
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index f64fbaa..4697fb6 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -600,7 +600,7 @@ static int ftrace_raw_init_event_##call(void) \
} \
\
static struct ftrace_event_call __used \
-__attribute__((__aligned__(4))) \
+__attribute__((__aligned__(32))) \
__attribute__((section("_ftrace_events"))) event_##call = { \
.name = #call, \
.system = __stringify(TRACE_SYSTEM), \
^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-02 21:12 ` Jason Baron
@ 2009-10-04 17:41 ` Ingo Molnar
2009-10-05 0:10 ` Justin Mattock
2009-10-06 1:24 ` Steven Rostedt
1 sibling, 1 reply; 62+ messages in thread
From: Ingo Molnar @ 2009-10-04 17:41 UTC (permalink / raw)
To: Jason Baron
Cc: Justin Mattock, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
* Jason Baron <jbaron@redhat.com> wrote:
> On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
> > >>
> > >> * Justin P. Mattock<justinmattock@gmail.com> wrote:
> > >>
> > >>
> > >>>
> > >>> Ingo Molnar wrote:
> > >>>
> > >>>>
> > >>>> * Justin Mattock<justinmattock@gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> O.K. I feel better, deleted
> > >>>>> my system, and threw in a minimal built system
> > >>>>> with only the bare essentials to boot.
> > >>>>> (just to make sure things are correct).
> > >>>>>
> > >>>>> unfortunately after building rc6 I'm still hitting
> > >>>>> this. really am not sure why this is happening.
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> Could you please double-check the bisection result by doing this:
> > >>>>
> > >>>> git revert af6af30c0f
> > >>>>
> > >>>> on the latest kernel and seeing whether that fixes the lockup?
> > >>>>
> > >>>> Bisections are very efficient and hence very sensitive as well to
> > >>>> minimal errors. Just one small mistake near the end of a bisection
> > >>>> can blame the wrong commit.
> > >>>>
> > >>>> So the best way to double-check such 100%-triggerable crashes is to
> > >>>> do the revert. I tried the revert and it can be done fine here.
> > >>>>
> > >>>> [ _If_ that does not fix the bug then to save time you can
> > >>>> 'backtrack' the bisection, instead of re-doing it completely.
> > >>>> I.e. you have your bisection log, re-check the final steps going
> > >>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
> > >>>> is 'good' or the other way around), redo the bisection log
> > >>>> commands up to that point and continue it up to the end. ]
> > >>>>
> > >>>> Ingo
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> shoot, I did not see your post here. when looking at my bisect
> > >>> log, I guess after a git bisect reset it clears?
> > >>>
> > >>> Anyways after git bisect had finished I looked manually at the
> > >>> commits that it had generated the one which I had sent in a post
> > >>> previously, and this one:
> > >>>
> > >>> 9424edc2da097c8589fcc24a72552d33e54be161
> > >>>
> > >>
> > >> (this commit has no effect on your kernel image, at all.)
> > >>
> > >>
> > >
> > > yep. but it was worth a try.
> > >>>
> > >>> at the time looking at the commit, I see this to be more of the
> > >>> cause because of it being related to elf as so forth, but as soon
> > >>> as I reverted this on rc6 made no difference.(the previous commit
> > >>> fixes this for me, on a regular tar.ball as well as in git.
> > >>>
> > >>> I think at this point since this system is a fresh from scratch
> > >>> build, I think something might be wrong that I'm doing (all the
> > >>> CFLAGS, and such are in a previous post).
> > >>>
> > >>> At the moment I don't have a problem applying a patch to the
> > >>> kernel for this. especially since I'm the only one that seems to
> > >>> be hitting this, then if more and more reports of this happen then
> > >>> we can go from there.
> > >>>
> > >>
> > >> What would be nice is to verify your bisection end result, i.e. do
> > >> what i suggested:
> > >>
> > >>
> > >
> > > yeah I've done this on both kernels three to be exact, and all boot after
> > > reverting
> > > Fix perf-tracepoint OOPS.
> > >
> > > As for my system, I'm still convinced that I might be doing something wrong
> > > over here.
> > >
> > >>>> Could you please double-check the bisection result by doing this:
> > >>>>
> > >>>> git revert af6af30c0f
> > >>>>
> > >>>> on the latest kernel and seeing whether that fixes the lockup?
> > >>>>
> > >>
> > >> if this doesnt fix it on latest -git then this commit is not the
> > >> cause of the lockup.
> > >>
> > >> Ingo
> > >>
> > >>
> > >
> > > This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
> > > well as others asking
> > > the question of why.
> > > In any case I still think I'm setting something wrong with either gcc, or
> > > something
> > > that might be causing this from userland.
> > >
> > > Justin P. Mattock
> > >
> >
> > O.k. here something awkward about this issue I was
> > experiencing. at the moment I have two imac's
> > here the descriptions:
> >
> > imac A) the one with the problem
> >
> > OS: built from the clfs book
> > x86_64 multilib with only lib64
> >
> > built everything with these flags:
> > CFLAGS="-m64 -mtune=core2 -march=core2
> > -mfpmath=both -O2 -pipe -fomit-frame-pointer
> > -fstack-protection"
> > CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
> > while compiling everything with
> > gcc version: 4.5.0 20090730
> >
> >
> > imac B) the one that works
> >
> > OS: clfs(just built a few days ago)
> > x86_64 pure64 bit build
> > (lib with a symlink to lib64)
> > CFLAGS="-m64 -mtune=core2 -march=core2
> > -O2 -pipe -fomit-frame-pointer"
> > CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
> > gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
> >
> > The only things I can think of is either I hit something
> > because of gcc, something goes wrong with the libraries,
> > or there something happening with either the option
> > of mfpmath=both or stackprotection.
> >
> > At this point since the kernel seems to be running fine,
> > is to just trash the system that has this issue and just leave
> > it at, I was hitting some weird anomaly.
> >
>
> hi Justin,
>
> I've been playing around with gcc '4.5' as well and hit a panic that
> looks very similar to what you've seen with stock 2.6.31 - I haven't
> seen it anywhere else. Anyways, it seems to be some sort of alignment
> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
> compiler or kernel issue. But the following kernel patch fixes the issue
> for me. It would be interesting to verify if the patch also resolves the
> issue for you.
Would be nice to know precisely what kind of problem is being hit here -
we'd like to fix either the kernel or GCC - depending on where the bug
lies.
Ingo
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-04 17:41 ` Ingo Molnar
@ 2009-10-05 0:10 ` Justin Mattock
2009-10-06 1:00 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Justin Mattock @ 2009-10-05 0:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jason Baron, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
On Sun, Oct 4, 2009 at 10:41 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Jason Baron <jbaron@redhat.com> wrote:
>
>> On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
>> > >>
>> > >> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>> > >>
>> > >>
>> > >>>
>> > >>> Ingo Molnar wrote:
>> > >>>
>> > >>>>
>> > >>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>>
>> > >>>>> O.K. I feel better, deleted
>> > >>>>> my system, and threw in a minimal built system
>> > >>>>> with only the bare essentials to boot.
>> > >>>>> (just to make sure things are correct).
>> > >>>>>
>> > >>>>> unfortunately after building rc6 I'm still hitting
>> > >>>>> this. really am not sure why this is happening.
>> > >>>>>
>> > >>>>>
>> > >>>>
>> > >>>> Could you please double-check the bisection result by doing this:
>> > >>>>
>> > >>>> git revert af6af30c0f
>> > >>>>
>> > >>>> on the latest kernel and seeing whether that fixes the lockup?
>> > >>>>
>> > >>>> Bisections are very efficient and hence very sensitive as well to
>> > >>>> minimal errors. Just one small mistake near the end of a bisection
>> > >>>> can blame the wrong commit.
>> > >>>>
>> > >>>> So the best way to double-check such 100%-triggerable crashes is to
>> > >>>> do the revert. I tried the revert and it can be done fine here.
>> > >>>>
>> > >>>> [ _If_ that does not fix the bug then to save time you can
>> > >>>> 'backtrack' the bisection, instead of re-doing it completely.
>> > >>>> I.e. you have your bisection log, re-check the final steps going
>> > >>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>> > >>>> is 'good' or the other way around), redo the bisection log
>> > >>>> commands up to that point and continue it up to the end. ]
>> > >>>>
>> > >>>> Ingo
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>> shoot, I did not see your post here. when looking at my bisect
>> > >>> log, I guess after a git bisect reset it clears?
>> > >>>
>> > >>> Anyways after git bisect had finished I looked manually at the
>> > >>> commits that it had generated the one which I had sent in a post
>> > >>> previously, and this one:
>> > >>>
>> > >>> 9424edc2da097c8589fcc24a72552d33e54be161
>> > >>>
>> > >>
>> > >> (this commit has no effect on your kernel image, at all.)
>> > >>
>> > >>
>> > >
>> > > yep. but it was worth a try.
>> > >>>
>> > >>> at the time looking at the commit, I see this to be more of the
>> > >>> cause because of it being related to elf as so forth, but as soon
>> > >>> as I reverted this on rc6 made no difference.(the previous commit
>> > >>> fixes this for me, on a regular tar.ball as well as in git.
>> > >>>
>> > >>> I think at this point since this system is a fresh from scratch
>> > >>> build, I think something might be wrong that I'm doing (all the
>> > >>> CFLAGS, and such are in a previous post).
>> > >>>
>> > >>> At the moment I don't have a problem applying a patch to the
>> > >>> kernel for this. especially since I'm the only one that seems to
>> > >>> be hitting this, then if more and more reports of this happen then
>> > >>> we can go from there.
>> > >>>
>> > >>
>> > >> What would be nice is to verify your bisection end result, i.e. do
>> > >> what i suggested:
>> > >>
>> > >>
>> > >
>> > > yeah I've done this on both kernels three to be exact, and all boot after
>> > > reverting
>> > > Fix perf-tracepoint OOPS.
>> > >
>> > > As for my system, I'm still convinced that I might be doing something wrong
>> > > over here.
>> > >
>> > >>>> Could you please double-check the bisection result by doing this:
>> > >>>>
>> > >>>> git revert af6af30c0f
>> > >>>>
>> > >>>> on the latest kernel and seeing whether that fixes the lockup?
>> > >>>>
>> > >>
>> > >> if this doesnt fix it on latest -git then this commit is not the
>> > >> cause of the lockup.
>> > >>
>> > >> Ingo
>> > >>
>> > >>
>> > >
>> > > This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
>> > > well as others asking
>> > > the question of why.
>> > > In any case I still think I'm setting something wrong with either gcc, or
>> > > something
>> > > that might be causing this from userland.
>> > >
>> > > Justin P. Mattock
>> > >
>> >
>> > O.k. here something awkward about this issue I was
>> > experiencing. at the moment I have two imac's
>> > here the descriptions:
>> >
>> > imac A) the one with the problem
>> >
>> > OS: built from the clfs book
>> > x86_64 multilib with only lib64
>> >
>> > built everything with these flags:
>> > CFLAGS="-m64 -mtune=core2 -march=core2
>> > -mfpmath=both -O2 -pipe -fomit-frame-pointer
>> > -fstack-protection"
>> > CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>> > while compiling everything with
>> > gcc version: 4.5.0 20090730
>> >
>> >
>> > imac B) the one that works
>> >
>> > OS: clfs(just built a few days ago)
>> > x86_64 pure64 bit build
>> > (lib with a symlink to lib64)
>> > CFLAGS="-m64 -mtune=core2 -march=core2
>> > -O2 -pipe -fomit-frame-pointer"
>> > CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>> > gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
>> >
>> > The only things I can think of is either I hit something
>> > because of gcc, something goes wrong with the libraries,
>> > or there something happening with either the option
>> > of mfpmath=both or stackprotection.
>> >
>> > At this point since the kernel seems to be running fine,
>> > is to just trash the system that has this issue and just leave
>> > it at, I was hitting some weird anomaly.
>> >
>>
>> hi Justin,
>>
>> I've been playing around with gcc '4.5' as well and hit a panic that
>> looks very similar to what you've seen with stock 2.6.31 - I haven't
>> seen it anywhere else. Anyways, it seems to be some sort of alignment
>> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
>> compiler or kernel issue. But the following kernel patch fixes the issue
>> for me. It would be interesting to verify if the patch also resolves the
>> issue for you.
>
> Would be nice to know precisely what kind of problem is being hit here -
> we'd like to fix either the kernel or GCC - depending on where the bug
> lies.
>
> Ingo
>
So I wasn't going crazy....
Anyways that system(clfs)
I still have, I can go ahead and
put it back on the machine and see if I hit this
again(keep in mind, just got back from a 7hr drive,
so it might be tomorrow).
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-05 0:10 ` Justin Mattock
@ 2009-10-06 1:00 ` Justin P. Mattock
2009-10-06 1:18 ` Steven Rostedt
2009-10-06 14:31 ` Jason Baron
0 siblings, 2 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-06 1:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jason Baron, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
Justin Mattock wrote:
> On Sun, Oct 4, 2009 at 10:41 AM, Ingo Molnar<mingo@elte.hu> wrote:
>
>> * Jason Baron<jbaron@redhat.com> wrote:
>>
>>
>>> On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
>>>
>>>>>> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ingo Molnar wrote:
>>>>>>>
>>>>>>>
>>>>>>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> O.K. I feel better, deleted
>>>>>>>>> my system, and threw in a minimal built system
>>>>>>>>> with only the bare essentials to boot.
>>>>>>>>> (just to make sure things are correct).
>>>>>>>>>
>>>>>>>>> unfortunately after building rc6 I'm still hitting
>>>>>>>>> this. really am not sure why this is happening.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>
>>>>>>>> git revert af6af30c0f
>>>>>>>>
>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>
>>>>>>>> Bisections are very efficient and hence very sensitive as well to
>>>>>>>> minimal errors. Just one small mistake near the end of a bisection
>>>>>>>> can blame the wrong commit.
>>>>>>>>
>>>>>>>> So the best way to double-check such 100%-triggerable crashes is to
>>>>>>>> do the revert. I tried the revert and it can be done fine here.
>>>>>>>>
>>>>>>>> [ _If_ that does not fix the bug then to save time you can
>>>>>>>> 'backtrack' the bisection, instead of re-doing it completely.
>>>>>>>> I.e. you have your bisection log, re-check the final steps going
>>>>>>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>>>>>>>> is 'good' or the other way around), redo the bisection log
>>>>>>>> commands up to that point and continue it up to the end. ]
>>>>>>>>
>>>>>>>> Ingo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> shoot, I did not see your post here. when looking at my bisect
>>>>>>> log, I guess after a git bisect reset it clears?
>>>>>>>
>>>>>>> Anyways after git bisect had finished I looked manually at the
>>>>>>> commits that it had generated the one which I had sent in a post
>>>>>>> previously, and this one:
>>>>>>>
>>>>>>> 9424edc2da097c8589fcc24a72552d33e54be161
>>>>>>>
>>>>>>>
>>>>>> (this commit has no effect on your kernel image, at all.)
>>>>>>
>>>>>>
>>>>>>
>>>>> yep. but it was worth a try.
>>>>>
>>>>>>> at the time looking at the commit, I see this to be more of the
>>>>>>> cause because of it being related to elf as so forth, but as soon
>>>>>>> as I reverted this on rc6 made no difference.(the previous commit
>>>>>>> fixes this for me, on a regular tar.ball as well as in git.
>>>>>>>
>>>>>>> I think at this point since this system is a fresh from scratch
>>>>>>> build, I think something might be wrong that I'm doing (all the
>>>>>>> CFLAGS, and such are in a previous post).
>>>>>>>
>>>>>>> At the moment I don't have a problem applying a patch to the
>>>>>>> kernel for this. especially since I'm the only one that seems to
>>>>>>> be hitting this, then if more and more reports of this happen then
>>>>>>> we can go from there.
>>>>>>>
>>>>>>>
>>>>>> What would be nice is to verify your bisection end result, i.e. do
>>>>>> what i suggested:
>>>>>>
>>>>>>
>>>>>>
>>>>> yeah I've done this on both kernels three to be exact, and all boot after
>>>>> reverting
>>>>> Fix perf-tracepoint OOPS.
>>>>>
>>>>> As for my system, I'm still convinced that I might be doing something wrong
>>>>> over here.
>>>>>
>>>>>
>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>
>>>>>>>> git revert af6af30c0f
>>>>>>>>
>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>
>>>>>>>>
>>>>>> if this doesnt fix it on latest -git then this commit is not the
>>>>>> cause of the lockup.
>>>>>>
>>>>>> Ingo
>>>>>>
>>>>>>
>>>>>>
>>>>> This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
>>>>> well as others asking
>>>>> the question of why.
>>>>> In any case I still think I'm setting something wrong with either gcc, or
>>>>> something
>>>>> that might be causing this from userland.
>>>>>
>>>>> Justin P. Mattock
>>>>>
>>>>>
>>>> O.k. here something awkward about this issue I was
>>>> experiencing. at the moment I have two imac's
>>>> here the descriptions:
>>>>
>>>> imac A) the one with the problem
>>>>
>>>> OS: built from the clfs book
>>>> x86_64 multilib with only lib64
>>>>
>>>> built everything with these flags:
>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>> -mfpmath=both -O2 -pipe -fomit-frame-pointer
>>>> -fstack-protection"
>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>> while compiling everything with
>>>> gcc version: 4.5.0 20090730
>>>>
>>>>
>>>> imac B) the one that works
>>>>
>>>> OS: clfs(just built a few days ago)
>>>> x86_64 pure64 bit build
>>>> (lib with a symlink to lib64)
>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>> -O2 -pipe -fomit-frame-pointer"
>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>> gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
>>>>
>>>> The only things I can think of is either I hit something
>>>> because of gcc, something goes wrong with the libraries,
>>>> or there something happening with either the option
>>>> of mfpmath=both or stackprotection.
>>>>
>>>> At this point since the kernel seems to be running fine,
>>>> is to just trash the system that has this issue and just leave
>>>> it at, I was hitting some weird anomaly.
>>>>
>>>>
>>> hi Justin,
>>>
>>> I've been playing around with gcc '4.5' as well and hit a panic that
>>> looks very similar to what you've seen with stock 2.6.31 - I haven't
>>> seen it anywhere else. Anyways, it seems to be some sort of alignment
>>> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
>>> compiler or kernel issue. But the following kernel patch fixes the issue
>>> for me. It would be interesting to verify if the patch also resolves the
>>> issue for you.
>>>
>> Would be nice to know precisely what kind of problem is being hit here -
>> we'd like to fix either the kernel or GCC - depending on where the bug
>> lies.
>>
>> Ingo
>>
>>
>
> So I wasn't going crazy....
> Anyways that system(clfs)
> I still have, I can go ahead and
> put it back on the machine and see if I hit this
> again(keep in mind, just got back from a 7hr drive,
> so it might be tomorrow).
>
>
o.k. I put back on that system, and
hit the error. I add your patch to 2.6.31-rc6,
and the latest git(a few days old).
I still am hitting this, but with your patch
I'm able to see the beginning of this panic:
(Ill write it manually)
[ 2.523966] kernel panic - not syncing: No init found. try passing
init= option
to the kernel
[ 2.524394] Pid: 1, comm: swapper Not tainted 2.6.31-rc6 #6
[ 2.524633] Call Trace:
[ 2.524875] [<ffffffff813a5b72>] panic+0x75/0x120
[ 2.525119] [<ffffffff8100910f>] init_post+0xef/0xf5
[ 2.525357] [<ffffffff815f6cf0>] kernel_init+0x198/0x1a3
[ 2.525600] [<ffffffff8102410a>] child_rip+0xa/0x20
[ 2.525842] [<ffffffff815f6b58>] ? kernel_init+0x0/0x1a3
[ 2.526084] [>ffffffff810224100>] ? child_rip+0x0/0x20
Seems I only hit this with using gcc 4.5.0 and compiling
sysvinit with SELinux support to load the policy at boot.
(here's the patch I used
http://readlist.com/lists/tycho.nsa.gov/selinux/3/15451.html).
Sound's like gcc is doing something(correct me if I'm
wrong) because the other systems I have are using the same
packages except for and older version of gcc.
maybe I should update sysvinit with a better patch to load the policy.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 1:00 ` Justin P. Mattock
@ 2009-10-06 1:18 ` Steven Rostedt
2009-10-06 2:01 ` Justin P. Mattock
2009-10-06 14:31 ` Jason Baron
1 sibling, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-06 1:18 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Ingo Molnar, Jason Baron, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Mon, 2009-10-05 at 18:00 -0700, Justin P. Mattock wrote:
> Justin Mattock wrote:
> o.k. I put back on that system, and
> hit the error. I add your patch to 2.6.31-rc6,
> and the latest git(a few days old).
> I still am hitting this, but with your patch
> I'm able to see the beginning of this panic:
> (Ill write it manually)
>
> [ 2.523966] kernel panic - not syncing: No init found. try passing
> init= option
> to the kernel
> [ 2.524394] Pid: 1, comm: swapper Not tainted 2.6.31-rc6 #6
> [ 2.524633] Call Trace:
> [ 2.524875] [<ffffffff813a5b72>] panic+0x75/0x120
> [ 2.525119] [<ffffffff8100910f>] init_post+0xef/0xf5
Strange. This panic is just telling you it could not find an "init" to
execute.
-- Steve
> [ 2.525357] [<ffffffff815f6cf0>] kernel_init+0x198/0x1a3
> [ 2.525600] [<ffffffff8102410a>] child_rip+0xa/0x20
> [ 2.525842] [<ffffffff815f6b58>] ? kernel_init+0x0/0x1a3
> [ 2.526084] [>ffffffff810224100>] ? child_rip+0x0/0x20
>
> Seems I only hit this with using gcc 4.5.0 and compiling
> sysvinit with SELinux support to load the policy at boot.
> (here's the patch I used
> http://readlist.com/lists/tycho.nsa.gov/selinux/3/15451.html).
>
> Sound's like gcc is doing something(correct me if I'm
> wrong) because the other systems I have are using the same
> packages except for and older version of gcc.
> maybe I should update sysvinit with a better patch to load the policy.
>
> Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-02 21:12 ` Jason Baron
2009-10-04 17:41 ` Ingo Molnar
@ 2009-10-06 1:24 ` Steven Rostedt
2009-10-06 20:32 ` Jason Baron
1 sibling, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-06 1:24 UTC (permalink / raw)
To: Jason Baron
Cc: Justin Mattock, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Fri, 2009-10-02 at 17:12 -0400, Jason Baron wrote:
> hi Justin,
>
> I've been playing around with gcc '4.5' as well and hit a panic that
> looks very similar to what you've seen with stock 2.6.31 - I haven't
> seen it anywhere else. Anyways, it seems to be some sort of alignment
> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
> compiler or kernel issue. But the following kernel patch fixes the issue
> for me. It would be interesting to verify if the patch also resolves the
> issue for you.
>
> thanks,
>
> -Jason
>
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 6ad76bf..0029af4 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -164,6 +164,7 @@
> LIKELY_PROFILE() \
> BRANCH_PROFILE() \
> TRACE_PRINTKS() \
> + . = ALIGN(32); \
> FTRACE_EVENTS() \
> TRACE_SYSCALLS()
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index a81170d..43f9f1e 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -124,7 +124,7 @@ struct ftrace_event_call {
> atomic_t profile_count;
> int (*profile_enable)(struct ftrace_event_call *);
> void (*profile_disable)(struct ftrace_event_call *);
> -};
> +} __attribute__((aligned(32)));
>
> #define MAX_FILTER_PRED 32
> #define MAX_FILTER_STR_VAL 128
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index f64fbaa..4697fb6 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -600,7 +600,7 @@ static int ftrace_raw_init_event_##call(void) \
> } \
> \
> static struct ftrace_event_call __used \
> -__attribute__((__aligned__(4))) \
> +__attribute__((__aligned__(32))) \
> __attribute__((section("_ftrace_events"))) event_##call = { \
> .name = #call, \
> .system = __stringify(TRACE_SYSTEM), \
Are all alignments needed? Or just adding one might help. Or removing
the one directly above?
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 1:18 ` Steven Rostedt
@ 2009-10-06 2:01 ` Justin P. Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-06 2:01 UTC (permalink / raw)
To: rostedt
Cc: Ingo Molnar, Jason Baron, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Mon, 2009-10-05 at 18:00 -0700, Justin P. Mattock wrote:
>
>> Justin Mattock wrote:
>>
>
>
>> o.k. I put back on that system, and
>> hit the error. I add your patch to 2.6.31-rc6,
>> and the latest git(a few days old).
>> I still am hitting this, but with your patch
>> I'm able to see the beginning of this panic:
>> (Ill write it manually)
>>
>> [ 2.523966] kernel panic - not syncing: No init found. try passing
>> init= option
>> to the kernel
>> [ 2.524394] Pid: 1, comm: swapper Not tainted 2.6.31-rc6 #6
>> [ 2.524633] Call Trace:
>> [ 2.524875] [<ffffffff813a5b72>] panic+0x75/0x120
>> [ 2.525119] [<ffffffff8100910f>] init_post+0xef/0xf5
>>
>
> Strange. This panic is just telling you it could not find an "init" to
> execute.
>
>
It is strange, my only guess is something gcc
is doing(like mentioned other systems I have run fine
while using gcc 4.4)
> -- Steve
>
>
>> [ 2.525357] [<ffffffff815f6cf0>] kernel_init+0x198/0x1a3
>> [ 2.525600] [<ffffffff8102410a>] child_rip+0xa/0x20
>> [ 2.525842] [<ffffffff815f6b58>] ? kernel_init+0x0/0x1a3
>> [ 2.526084] [>ffffffff810224100>] ? child_rip+0x0/0x20
>>
>> Seems I only hit this with using gcc 4.5.0 and compiling
>> sysvinit with SELinux support to load the policy at boot.
>> (here's the patch I used
>> http://readlist.com/lists/tycho.nsa.gov/selinux/3/15451.html).
>>
>> Sound's like gcc is doing something(correct me if I'm
>> wrong) because the other systems I have are using the same
>> packages except for and older version of gcc.
>> maybe I should update sysvinit with a better patch to load the policy.
>>
>> Justin P. Mattock
>>
>
>
>
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 1:00 ` Justin P. Mattock
2009-10-06 1:18 ` Steven Rostedt
@ 2009-10-06 14:31 ` Jason Baron
2009-10-06 15:12 ` Justin P. Mattock
1 sibling, 1 reply; 62+ messages in thread
From: Jason Baron @ 2009-10-06 14:31 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Ingo Molnar, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
On Mon, Oct 05, 2009 at 06:00:41PM -0700, Justin P. Mattock wrote:
> Justin Mattock wrote:
>> On Sun, Oct 4, 2009 at 10:41 AM, Ingo Molnar<mingo@elte.hu> wrote:
>>
>>> * Jason Baron<jbaron@redhat.com> wrote:
>>>
>>>
>>>> On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
>>>>
>>>>>>> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Ingo Molnar wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> O.K. I feel better, deleted
>>>>>>>>>> my system, and threw in a minimal built system
>>>>>>>>>> with only the bare essentials to boot.
>>>>>>>>>> (just to make sure things are correct).
>>>>>>>>>>
>>>>>>>>>> unfortunately after building rc6 I'm still hitting
>>>>>>>>>> this. really am not sure why this is happening.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>>
>>>>>>>>> git revert af6af30c0f
>>>>>>>>>
>>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>>
>>>>>>>>> Bisections are very efficient and hence very sensitive as well to
>>>>>>>>> minimal errors. Just one small mistake near the end of a bisection
>>>>>>>>> can blame the wrong commit.
>>>>>>>>>
>>>>>>>>> So the best way to double-check such 100%-triggerable crashes is to
>>>>>>>>> do the revert. I tried the revert and it can be done fine here.
>>>>>>>>>
>>>>>>>>> [ _If_ that does not fix the bug then to save time you can
>>>>>>>>> 'backtrack' the bisection, instead of re-doing it completely.
>>>>>>>>> I.e. you have your bisection log, re-check the final steps going
>>>>>>>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>>>>>>>>> is 'good' or the other way around), redo the bisection log
>>>>>>>>> commands up to that point and continue it up to the end. ]
>>>>>>>>>
>>>>>>>>> Ingo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> shoot, I did not see your post here. when looking at my bisect
>>>>>>>> log, I guess after a git bisect reset it clears?
>>>>>>>>
>>>>>>>> Anyways after git bisect had finished I looked manually at the
>>>>>>>> commits that it had generated the one which I had sent in a post
>>>>>>>> previously, and this one:
>>>>>>>>
>>>>>>>> 9424edc2da097c8589fcc24a72552d33e54be161
>>>>>>>>
>>>>>>>>
>>>>>>> (this commit has no effect on your kernel image, at all.)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> yep. but it was worth a try.
>>>>>>
>>>>>>>> at the time looking at the commit, I see this to be more of the
>>>>>>>> cause because of it being related to elf as so forth, but as soon
>>>>>>>> as I reverted this on rc6 made no difference.(the previous commit
>>>>>>>> fixes this for me, on a regular tar.ball as well as in git.
>>>>>>>>
>>>>>>>> I think at this point since this system is a fresh from scratch
>>>>>>>> build, I think something might be wrong that I'm doing (all the
>>>>>>>> CFLAGS, and such are in a previous post).
>>>>>>>>
>>>>>>>> At the moment I don't have a problem applying a patch to the
>>>>>>>> kernel for this. especially since I'm the only one that seems to
>>>>>>>> be hitting this, then if more and more reports of this happen then
>>>>>>>> we can go from there.
>>>>>>>>
>>>>>>>>
>>>>>>> What would be nice is to verify your bisection end result, i.e. do
>>>>>>> what i suggested:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> yeah I've done this on both kernels three to be exact, and all boot after
>>>>>> reverting
>>>>>> Fix perf-tracepoint OOPS.
>>>>>>
>>>>>> As for my system, I'm still convinced that I might be doing something wrong
>>>>>> over here.
>>>>>>
>>>>>>
>>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>>
>>>>>>>>> git revert af6af30c0f
>>>>>>>>>
>>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>>
>>>>>>>>>
>>>>>>> if this doesnt fix it on latest -git then this commit is not the
>>>>>>> cause of the lockup.
>>>>>>>
>>>>>>> Ingo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
>>>>>> well as others asking
>>>>>> the question of why.
>>>>>> In any case I still think I'm setting something wrong with either gcc, or
>>>>>> something
>>>>>> that might be causing this from userland.
>>>>>>
>>>>>> Justin P. Mattock
>>>>>>
>>>>>>
>>>>> O.k. here something awkward about this issue I was
>>>>> experiencing. at the moment I have two imac's
>>>>> here the descriptions:
>>>>>
>>>>> imac A) the one with the problem
>>>>>
>>>>> OS: built from the clfs book
>>>>> x86_64 multilib with only lib64
>>>>>
>>>>> built everything with these flags:
>>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>>> -mfpmath=both -O2 -pipe -fomit-frame-pointer
>>>>> -fstack-protection"
>>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>>> while compiling everything with
>>>>> gcc version: 4.5.0 20090730
>>>>>
>>>>>
>>>>> imac B) the one that works
>>>>>
>>>>> OS: clfs(just built a few days ago)
>>>>> x86_64 pure64 bit build
>>>>> (lib with a symlink to lib64)
>>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>>> -O2 -pipe -fomit-frame-pointer"
>>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>>> gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
>>>>>
>>>>> The only things I can think of is either I hit something
>>>>> because of gcc, something goes wrong with the libraries,
>>>>> or there something happening with either the option
>>>>> of mfpmath=both or stackprotection.
>>>>>
>>>>> At this point since the kernel seems to be running fine,
>>>>> is to just trash the system that has this issue and just leave
>>>>> it at, I was hitting some weird anomaly.
>>>>>
>>>>>
>>>> hi Justin,
>>>>
>>>> I've been playing around with gcc '4.5' as well and hit a panic that
>>>> looks very similar to what you've seen with stock 2.6.31 - I haven't
>>>> seen it anywhere else. Anyways, it seems to be some sort of alignment
>>>> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
>>>> compiler or kernel issue. But the following kernel patch fixes the issue
>>>> for me. It would be interesting to verify if the patch also resolves the
>>>> issue for you.
>>>>
>>> Would be nice to know precisely what kind of problem is being hit here -
>>> we'd like to fix either the kernel or GCC - depending on where the bug
>>> lies.
>>>
>>> Ingo
>>>
>>>
>>
>> So I wasn't going crazy....
>> Anyways that system(clfs)
>> I still have, I can go ahead and
>> put it back on the machine and see if I hit this
>> again(keep in mind, just got back from a 7hr drive,
>> so it might be tomorrow).
>>
>>
> o.k. I put back on that system, and
> hit the error. I add your patch to 2.6.31-rc6,
ok. is that error, the same as the error below? The error below looks
completely different from the posted previously. So, it almost looks
like you the patch fixed one problem, only to reveal another one. Is
that correct?
> and the latest git(a few days old).
> I still am hitting this, but with your patch
> I'm able to see the beginning of this panic:
> (Ill write it manually)
>
> [ 2.523966] kernel panic - not syncing: No init found. try passing
> init= option
> to the kernel
> [ 2.524394] Pid: 1, comm: swapper Not tainted 2.6.31-rc6 #6
> [ 2.524633] Call Trace:
> [ 2.524875] [<ffffffff813a5b72>] panic+0x75/0x120
> [ 2.525119] [<ffffffff8100910f>] init_post+0xef/0xf5
> [ 2.525357] [<ffffffff815f6cf0>] kernel_init+0x198/0x1a3
> [ 2.525600] [<ffffffff8102410a>] child_rip+0xa/0x20
> [ 2.525842] [<ffffffff815f6b58>] ? kernel_init+0x0/0x1a3
> [ 2.526084] [>ffffffff810224100>] ? child_rip+0x0/0x20
>
> Seems I only hit this with using gcc 4.5.0 and compiling
> sysvinit with SELinux support to load the policy at boot.
> (here's the patch I used
> http://readlist.com/lists/tycho.nsa.gov/selinux/3/15451.html).
>
> Sound's like gcc is doing something(correct me if I'm
> wrong) because the other systems I have are using the same
> packages except for and older version of gcc.
> maybe I should update sysvinit with a better patch to load the policy.
>
> Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 14:31 ` Jason Baron
@ 2009-10-06 15:12 ` Justin P. Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-06 15:12 UTC (permalink / raw)
To: Jason Baron
Cc: Ingo Molnar, Peter Zijlstra, Li Zefan, Steven Rostedt,
Frederic Weisbecker, Linux Kernel Mailing List
Jason Baron wrote:
> On Mon, Oct 05, 2009 at 06:00:41PM -0700, Justin P. Mattock wrote:
>
>> Justin Mattock wrote:
>>
>>> On Sun, Oct 4, 2009 at 10:41 AM, Ingo Molnar<mingo@elte.hu> wrote:
>>>
>>>
>>>> * Jason Baron<jbaron@redhat.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Mon, Sep 07, 2009 at 02:49:44PM -0700, Justin Mattock wrote:
>>>>>
>>>>>
>>>>>>>> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Ingo Molnar wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> * Justin Mattock<justinmattock@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> O.K. I feel better, deleted
>>>>>>>>>>> my system, and threw in a minimal built system
>>>>>>>>>>> with only the bare essentials to boot.
>>>>>>>>>>> (just to make sure things are correct).
>>>>>>>>>>>
>>>>>>>>>>> unfortunately after building rc6 I'm still hitting
>>>>>>>>>>> this. really am not sure why this is happening.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>>>
>>>>>>>>>> git revert af6af30c0f
>>>>>>>>>>
>>>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>>>
>>>>>>>>>> Bisections are very efficient and hence very sensitive as well to
>>>>>>>>>> minimal errors. Just one small mistake near the end of a bisection
>>>>>>>>>> can blame the wrong commit.
>>>>>>>>>>
>>>>>>>>>> So the best way to double-check such 100%-triggerable crashes is to
>>>>>>>>>> do the revert. I tried the revert and it can be done fine here.
>>>>>>>>>>
>>>>>>>>>> [ _If_ that does not fix the bug then to save time you can
>>>>>>>>>> 'backtrack' the bisection, instead of re-doing it completely.
>>>>>>>>>> I.e. you have your bisection log, re-check the final steps going
>>>>>>>>>> backwards. Once you find a discrepancy (i.e. a 'bad' point that
>>>>>>>>>> is 'good' or the other way around), redo the bisection log
>>>>>>>>>> commands up to that point and continue it up to the end. ]
>>>>>>>>>>
>>>>>>>>>> Ingo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> shoot, I did not see your post here. when looking at my bisect
>>>>>>>>> log, I guess after a git bisect reset it clears?
>>>>>>>>>
>>>>>>>>> Anyways after git bisect had finished I looked manually at the
>>>>>>>>> commits that it had generated the one which I had sent in a post
>>>>>>>>> previously, and this one:
>>>>>>>>>
>>>>>>>>> 9424edc2da097c8589fcc24a72552d33e54be161
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> (this commit has no effect on your kernel image, at all.)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> yep. but it was worth a try.
>>>>>>>
>>>>>>>
>>>>>>>>> at the time looking at the commit, I see this to be more of the
>>>>>>>>> cause because of it being related to elf as so forth, but as soon
>>>>>>>>> as I reverted this on rc6 made no difference.(the previous commit
>>>>>>>>> fixes this for me, on a regular tar.ball as well as in git.
>>>>>>>>>
>>>>>>>>> I think at this point since this system is a fresh from scratch
>>>>>>>>> build, I think something might be wrong that I'm doing (all the
>>>>>>>>> CFLAGS, and such are in a previous post).
>>>>>>>>>
>>>>>>>>> At the moment I don't have a problem applying a patch to the
>>>>>>>>> kernel for this. especially since I'm the only one that seems to
>>>>>>>>> be hitting this, then if more and more reports of this happen then
>>>>>>>>> we can go from there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> What would be nice is to verify your bisection end result, i.e. do
>>>>>>>> what i suggested:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> yeah I've done this on both kernels three to be exact, and all boot after
>>>>>>> reverting
>>>>>>> Fix perf-tracepoint OOPS.
>>>>>>>
>>>>>>> As for my system, I'm still convinced that I might be doing something wrong
>>>>>>> over here.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> Could you please double-check the bisection result by doing this:
>>>>>>>>>>
>>>>>>>>>> git revert af6af30c0f
>>>>>>>>>>
>>>>>>>>>> on the latest kernel and seeing whether that fixes the lockup?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> if this doesnt fix it on latest -git then this commit is not the
>>>>>>>> cause of the lockup.
>>>>>>>>
>>>>>>>> Ingo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm left, as
>>>>>>> well as others asking
>>>>>>> the question of why.
>>>>>>> In any case I still think I'm setting something wrong with either gcc, or
>>>>>>> something
>>>>>>> that might be causing this from userland.
>>>>>>>
>>>>>>> Justin P. Mattock
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> O.k. here something awkward about this issue I was
>>>>>> experiencing. at the moment I have two imac's
>>>>>> here the descriptions:
>>>>>>
>>>>>> imac A) the one with the problem
>>>>>>
>>>>>> OS: built from the clfs book
>>>>>> x86_64 multilib with only lib64
>>>>>>
>>>>>> built everything with these flags:
>>>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>>>> -mfpmath=both -O2 -pipe -fomit-frame-pointer
>>>>>> -fstack-protection"
>>>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>>>> while compiling everything with
>>>>>> gcc version: 4.5.0 20090730
>>>>>>
>>>>>>
>>>>>> imac B) the one that works
>>>>>>
>>>>>> OS: clfs(just built a few days ago)
>>>>>> x86_64 pure64 bit build
>>>>>> (lib with a symlink to lib64)
>>>>>> CFLAGS="-m64 -mtune=core2 -march=core2
>>>>>> -O2 -pipe -fomit-frame-pointer"
>>>>>> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
>>>>>> gcc version: 4.4.1 (GCC for Cross-LFS 4.4.1.20090722)
>>>>>>
>>>>>> The only things I can think of is either I hit something
>>>>>> because of gcc, something goes wrong with the libraries,
>>>>>> or there something happening with either the option
>>>>>> of mfpmath=both or stackprotection.
>>>>>>
>>>>>> At this point since the kernel seems to be running fine,
>>>>>> is to just trash the system that has this issue and just leave
>>>>>> it at, I was hitting some weird anomaly.
>>>>>>
>>>>>>
>>>>>>
>>>>> hi Justin,
>>>>>
>>>>> I've been playing around with gcc '4.5' as well and hit a panic that
>>>>> looks very similar to what you've seen with stock 2.6.31 - I haven't
>>>>> seen it anywhere else. Anyways, it seems to be some sort of alignment
>>>>> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
>>>>> compiler or kernel issue. But the following kernel patch fixes the issue
>>>>> for me. It would be interesting to verify if the patch also resolves the
>>>>> issue for you.
>>>>>
>>>>>
>>>> Would be nice to know precisely what kind of problem is being hit here -
>>>> we'd like to fix either the kernel or GCC - depending on where the bug
>>>> lies.
>>>>
>>>> Ingo
>>>>
>>>>
>>>>
>>> So I wasn't going crazy....
>>> Anyways that system(clfs)
>>> I still have, I can go ahead and
>>> put it back on the machine and see if I hit this
>>> again(keep in mind, just got back from a 7hr drive,
>>> so it might be tomorrow).
>>>
>>>
>>>
>> o.k. I put back on that system, and
>> hit the error. I add your patch to 2.6.31-rc6,
>>
>
> ok. is that error, the same as the error below? The error below looks
> completely different from the posted previously. So, it almost looks
> like you the patch fixed one problem, only to reveal another one. Is
> that correct?
>
>
Could be a different error, the problem I have is capturing this error i.g.
tried ieee1394_dma=early to capture this, but that mechanism
seems to error out.(ssh no go either because this happens so early).
I think this is the top part of the error, because before adding your patch
the system would boot a little farther(to fast to read anything)down the
line,
and I did see something in there about a kernel panic.
If you have any ideas on how I can capture this early, would be
appreciated.
(getting anything to log this early is a bit tricky).
>> and the latest git(a few days old).
>> I still am hitting this, but with your patch
>> I'm able to see the beginning of this panic:
>> (Ill write it manually)
>>
>> [ 2.523966] kernel panic - not syncing: No init found. try passing
>> init= option
>> to the kernel
>> [ 2.524394] Pid: 1, comm: swapper Not tainted 2.6.31-rc6 #6
>> [ 2.524633] Call Trace:
>> [ 2.524875] [<ffffffff813a5b72>] panic+0x75/0x120
>> [ 2.525119] [<ffffffff8100910f>] init_post+0xef/0xf5
>> [ 2.525357] [<ffffffff815f6cf0>] kernel_init+0x198/0x1a3
>> [ 2.525600] [<ffffffff8102410a>] child_rip+0xa/0x20
>> [ 2.525842] [<ffffffff815f6b58>] ? kernel_init+0x0/0x1a3
>> [ 2.526084] [>ffffffff810224100>] ? child_rip+0x0/0x20
>>
>> Seems I only hit this with using gcc 4.5.0 and compiling
>> sysvinit with SELinux support to load the policy at boot.
>> (here's the patch I used
>> http://readlist.com/lists/tycho.nsa.gov/selinux/3/15451.html).
>>
>> Sound's like gcc is doing something(correct me if I'm
>> wrong) because the other systems I have are using the same
>> packages except for and older version of gcc.
>> maybe I should update sysvinit with a better patch to load the policy.
>>
>> Justin P. Mattock
>>
>
>
As a test Ill throw in a kernel that was compiled with gcc 4.4.0 just to
see if this is a compiler/kernel issue.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 1:24 ` Steven Rostedt
@ 2009-10-06 20:32 ` Jason Baron
2009-10-06 22:30 ` Justin P. Mattock
2009-10-07 2:02 ` Steven Rostedt
0 siblings, 2 replies; 62+ messages in thread
From: Jason Baron @ 2009-10-06 20:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Justin Mattock, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Mon, Oct 05, 2009 at 09:24:09PM -0400, Steven Rostedt wrote:
> On Fri, 2009-10-02 at 17:12 -0400, Jason Baron wrote:
>
> > hi Justin,
> >
> > I've been playing around with gcc '4.5' as well and hit a panic that
> > looks very similar to what you've seen with stock 2.6.31 - I haven't
> > seen it anywhere else. Anyways, it seems to be some sort of alignment
> > issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
> > compiler or kernel issue. But the following kernel patch fixes the issue
> > for me. It would be interesting to verify if the patch also resolves the
> > issue for you.
> >
> > thanks,
> >
> > -Jason
> >
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 6ad76bf..0029af4 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -164,6 +164,7 @@
> > LIKELY_PROFILE() \
> > BRANCH_PROFILE() \
> > TRACE_PRINTKS() \
> > + . = ALIGN(32); \
> > FTRACE_EVENTS() \
> > TRACE_SYSCALLS()
> >
> > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > index a81170d..43f9f1e 100644
> > --- a/include/linux/ftrace_event.h
> > +++ b/include/linux/ftrace_event.h
> > @@ -124,7 +124,7 @@ struct ftrace_event_call {
> > atomic_t profile_count;
> > int (*profile_enable)(struct ftrace_event_call *);
> > void (*profile_disable)(struct ftrace_event_call *);
> > -};
> > +} __attribute__((aligned(32)));
> >
> > #define MAX_FILTER_PRED 32
> > #define MAX_FILTER_STR_VAL 128
> > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > index f64fbaa..4697fb6 100644
> > --- a/include/trace/ftrace.h
> > +++ b/include/trace/ftrace.h
> > @@ -600,7 +600,7 @@ static int ftrace_raw_init_event_##call(void) \
> > } \
> > \
> > static struct ftrace_event_call __used \
> > -__attribute__((__aligned__(4))) \
> > +__attribute__((__aligned__(32))) \
> > __attribute__((section("_ftrace_events"))) event_##call = { \
> > .name = #call, \
> > .system = __stringify(TRACE_SYSTEM), \
>
> Are all alignments needed? Or just adding one might help. Or removing
> the one directly above?
>
> -- Steve
>
So the problem I'm seeing is an oops on boot caused by the call->system pointer
deference in event_create_dir(). The 'call' variable is of type 'struct
ftrace_event_call'.
What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
(sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
structures are 16-byte aligned. Thus, the stride for walking through the
pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
vanilla 2.6.31 kernel.
That said, I'm not sure the compiler is doing the wrong thing here. The
'struct ftrace_event_call' contains an embedded 'struct list_head' which
is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
minimum alignment for the variable or structure field, measured in bytes'.
Thus, at least according to the docs, gcc can increase the alignment of the
'struct ftrace_event_call', from its original specification of 4, to 16. Even
in the case where we are working corectly the structures are 8-byte aligned.
Thus, I would reccommend the patch below as a preventive measure. Its
the minimal patch I've found to resolve this issue. In general, if we
are going to walk data structures embedded in a special elf section, I
think the general rules needs to be to set the alignment to the power of
two which is greater than or equal to the largest item in the structure.
thanks,
-Jason
Signed-off-by: Jason Baron <jbaron@redhat.com>
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a81170d..7182f03 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -124,7 +124,10 @@ struct ftrace_event_call {
atomic_t profile_count;
int (*profile_enable)(struct ftrace_event_call *);
void (*profile_disable)(struct ftrace_event_call *);
-};
+} __attribute__((aligned(16)));
+
+/* Align to the largest field in the data structure:
+ * sizeof(struct list_head) = 16 */
#define MAX_FILTER_PRED 32
#define MAX_FILTER_STR_VAL 128
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index f64fbaa..e344e81 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -600,7 +600,6 @@ static int ftrace_raw_init_event_##call(void) \
} \
\
static struct ftrace_event_call __used \
-__attribute__((__aligned__(4))) \
__attribute__((section("_ftrace_events"))) event_##call = { \
.name = #call, \
.system = __stringify(TRACE_SYSTEM), \
^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 20:32 ` Jason Baron
@ 2009-10-06 22:30 ` Justin P. Mattock
2009-10-07 2:02 ` Steven Rostedt
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-06 22:30 UTC (permalink / raw)
To: Jason Baron
Cc: Steven Rostedt, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Jason Baron wrote:
> On Mon, Oct 05, 2009 at 09:24:09PM -0400, Steven Rostedt wrote:
>
>> On Fri, 2009-10-02 at 17:12 -0400, Jason Baron wrote:
>>
>>
>>> hi Justin,
>>>
>>> I've been playing around with gcc '4.5' as well and hit a panic that
>>> looks very similar to what you've seen with stock 2.6.31 - I haven't
>>> seen it anywhere else. Anyways, it seems to be some sort of alignment
>>> issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
>>> compiler or kernel issue. But the following kernel patch fixes the issue
>>> for me. It would be interesting to verify if the patch also resolves the
>>> issue for you.
>>>
>>> thanks,
>>>
>>> -Jason
>>>
>>>
>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>>> index 6ad76bf..0029af4 100644
>>> --- a/include/asm-generic/vmlinux.lds.h
>>> +++ b/include/asm-generic/vmlinux.lds.h
>>> @@ -164,6 +164,7 @@
>>> LIKELY_PROFILE() \
>>> BRANCH_PROFILE() \
>>> TRACE_PRINTKS() \
>>> + . = ALIGN(32); \
>>> FTRACE_EVENTS() \
>>> TRACE_SYSCALLS()
>>>
>>> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
>>> index a81170d..43f9f1e 100644
>>> --- a/include/linux/ftrace_event.h
>>> +++ b/include/linux/ftrace_event.h
>>> @@ -124,7 +124,7 @@ struct ftrace_event_call {
>>> atomic_t profile_count;
>>> int (*profile_enable)(struct ftrace_event_call *);
>>> void (*profile_disable)(struct ftrace_event_call *);
>>> -};
>>> +} __attribute__((aligned(32)));
>>>
>>> #define MAX_FILTER_PRED 32
>>> #define MAX_FILTER_STR_VAL 128
>>> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
>>> index f64fbaa..4697fb6 100644
>>> --- a/include/trace/ftrace.h
>>> +++ b/include/trace/ftrace.h
>>> @@ -600,7 +600,7 @@ static int ftrace_raw_init_event_##call(void) \
>>> } \
>>> \
>>> static struct ftrace_event_call __used \
>>> -__attribute__((__aligned__(4))) \
>>> +__attribute__((__aligned__(32))) \
>>> __attribute__((section("_ftrace_events"))) event_##call = { \
>>> .name = #call, \
>>> .system = __stringify(TRACE_SYSTEM), \
>>>
>> Are all alignments needed? Or just adding one might help. Or removing
>> the one directly above?
>>
>> -- Steve
>>
>>
>
> So the problem I'm seeing is an oops on boot caused by the call->system pointer
> deference in event_create_dir(). The 'call' variable is of type 'struct
> ftrace_event_call'.
>
> What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> structures are 16-byte aligned. Thus, the stride for walking through the
> pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
>
> I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> vanilla 2.6.31 kernel.
>
> That said, I'm not sure the compiler is doing the wrong thing here. The
> 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> minimum alignment for the variable or structure field, measured in bytes'.
> Thus, at least according to the docs, gcc can increase the alignment of the
> 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> in the case where we are working corectly the structures are 8-byte aligned.
>
> Thus, I would reccommend the patch below as a preventive measure. Its
> the minimal patch I've found to resolve this issue. In general, if we
> are going to walk data structures embedded in a special elf section, I
> think the general rules needs to be to set the alignment to the power of
> two which is greater than or equal to the largest item in the structure.
>
> thanks,
>
> -Jason
>
> Signed-off-by: Jason Baron<jbaron@redhat.com>
>
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index a81170d..7182f03 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -124,7 +124,10 @@ struct ftrace_event_call {
> atomic_t profile_count;
> int (*profile_enable)(struct ftrace_event_call *);
> void (*profile_disable)(struct ftrace_event_call *);
> -};
> +} __attribute__((aligned(16)));
> +
> +/* Align to the largest field in the data structure:
> + * sizeof(struct list_head) = 16 */
>
> #define MAX_FILTER_PRED 32
> #define MAX_FILTER_STR_VAL 128
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index f64fbaa..e344e81 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -600,7 +600,6 @@ static int ftrace_raw_init_event_##call(void) \
> } \
> \
> static struct ftrace_event_call __used \
> -__attribute__((__aligned__(4))) \
> __attribute__((section("_ftrace_events"))) event_##call = { \
> .name = #call, \
> .system = __stringify(TRACE_SYSTEM), \
>
>
>
>
>
shoot I don't know why this is still hitting.
tried both patches and still.
As of now the only thing I can think of besides looking
at kernel/compiler is the patch for sysvinit to load
the policy(maybe something in there is old/outdated).
(BTW: not sure if it means anything but this system is x86_64
built from the multilib clfs, but with no 32 bit libs, pretty much
how fedora11 has there system built)
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-06 20:32 ` Jason Baron
2009-10-06 22:30 ` Justin P. Mattock
@ 2009-10-07 2:02 ` Steven Rostedt
2009-10-07 2:42 ` Justin P. Mattock
2009-10-07 14:30 ` Jason Baron
1 sibling, 2 replies; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 2:02 UTC (permalink / raw)
To: Jason Baron
Cc: Justin Mattock, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Tue, 2009-10-06 at 16:32 -0400, Jason Baron wrote:
> So the problem I'm seeing is an oops on boot caused by the call->system pointer
> deference in event_create_dir(). The 'call' variable is of type 'struct
> ftrace_event_call'.
>
> What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> structures are 16-byte aligned. Thus, the stride for walking through the
> pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
>
> I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> vanilla 2.6.31 kernel.
>
> That said, I'm not sure the compiler is doing the wrong thing here. The
> 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> minimum alignment for the variable or structure field, measured in bytes'.
> Thus, at least according to the docs, gcc can increase the alignment of the
> 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> in the case where we are working corectly the structures are 8-byte aligned.
>
> Thus, I would reccommend the patch below as a preventive measure. Its
> the minimal patch I've found to resolve this issue. In general, if we
> are going to walk data structures embedded in a special elf section, I
> think the general rules needs to be to set the alignment to the power of
> two which is greater than or equal to the largest item in the structure.
>
> thanks,
>
> -Jason
>
> Signed-off-by: Jason Baron <jbaron@redhat.com>
>
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index a81170d..7182f03 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -124,7 +124,10 @@ struct ftrace_event_call {
> atomic_t profile_count;
> int (*profile_enable)(struct ftrace_event_call *);
> void (*profile_disable)(struct ftrace_event_call *);
> -};
> +} __attribute__((aligned(16)));
> +
> +/* Align to the largest field in the data structure:
> + * sizeof(struct list_head) = 16 */
Is this true for i386?
I just tried this patch and it seems to work. Can you give it a try.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4ec5e67..044b70d 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -133,7 +133,7 @@ struct ftrace_event_call {
atomic_t profile_count;
int (*profile_enable)(void);
void (*profile_disable)(void);
-};
+} __attribute__((aligned(sizeof(struct list_head))));
#define FTRACE_MAX_PROFILE_SIZE 2048
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index cc0d966..31e7637 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
* }
*
* static struct ftrace_event_call __used
- * __attribute__((__aligned__(4)))
* __attribute__((section("_ftrace_events"))) event_<call> = {
* .name = "<call>",
* .system = "<system>",
@@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
} \
\
static struct ftrace_event_call __used \
-__attribute__((__aligned__(4))) \
__attribute__((section("_ftrace_events"))) event_##call = { \
.name = #call, \
.system = __stringify(TRACE_SYSTEM), \
^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 2:02 ` Steven Rostedt
@ 2009-10-07 2:42 ` Justin P. Mattock
2009-10-07 13:00 ` Steven Rostedt
2009-10-07 14:30 ` Jason Baron
1 sibling, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 2:42 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 2009-10-06 at 16:32 -0400, Jason Baron wrote:
>
>
>> So the problem I'm seeing is an oops on boot caused by the call->system pointer
>> deference in event_create_dir(). The 'call' variable is of type 'struct
>> ftrace_event_call'.
>>
>> What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
>> (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
>> structures are 16-byte aligned. Thus, the stride for walking through the
>> pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
>>
>> I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
>> vanilla 2.6.31 kernel.
>>
>> That said, I'm not sure the compiler is doing the wrong thing here. The
>> 'struct ftrace_event_call' contains an embedded 'struct list_head' which
>> is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
>> minimum alignment for the variable or structure field, measured in bytes'.
>> Thus, at least according to the docs, gcc can increase the alignment of the
>> 'struct ftrace_event_call', from its original specification of 4, to 16. Even
>> in the case where we are working corectly the structures are 8-byte aligned.
>>
>> Thus, I would reccommend the patch below as a preventive measure. Its
>> the minimal patch I've found to resolve this issue. In general, if we
>> are going to walk data structures embedded in a special elf section, I
>> think the general rules needs to be to set the alignment to the power of
>> two which is greater than or equal to the largest item in the structure.
>>
>> thanks,
>>
>> -Jason
>>
>> Signed-off-by: Jason Baron<jbaron@redhat.com>
>>
>>
>> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
>> index a81170d..7182f03 100644
>> --- a/include/linux/ftrace_event.h
>> +++ b/include/linux/ftrace_event.h
>> @@ -124,7 +124,10 @@ struct ftrace_event_call {
>> atomic_t profile_count;
>> int (*profile_enable)(struct ftrace_event_call *);
>> void (*profile_disable)(struct ftrace_event_call *);
>> -};
>> +} __attribute__((aligned(16)));
>> +
>> +/* Align to the largest field in the data structure:
>> + * sizeof(struct list_head) = 16 */
>>
>
> Is this true for i386?
>
> I just tried this patch and it seems to work. Can you give it a try.
>
> Signed-off-by: Steven Rostedt<rostedt@goodmis.org>
>
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index 4ec5e67..044b70d 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -133,7 +133,7 @@ struct ftrace_event_call {
> atomic_t profile_count;
> int (*profile_enable)(void);
> void (*profile_disable)(void);
> -};
> +} __attribute__((aligned(sizeof(struct list_head))));
>
> #define FTRACE_MAX_PROFILE_SIZE 2048
>
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index cc0d966..31e7637 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
> * }
> *
> * static struct ftrace_event_call __used
> - * __attribute__((__aligned__(4)))
> * __attribute__((section("_ftrace_events"))) event_<call> = {
> * .name = "<call>",
> * .system = "<system>",
> @@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
> } \
> \
> static struct ftrace_event_call __used \
> -__attribute__((__aligned__(4))) \
> __attribute__((section("_ftrace_events"))) event_##call = { \
> .name = #call, \
> .system = __stringify(TRACE_SYSTEM), \
>
>
>
>
o.k. applied your patch, but unfortunantly
I still am hitting this kernel panic.
must admit I have no idea why this is doing this.
(but am willing to sit through this, because eventually
sooner or later will hit this if I update gcc).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 2:42 ` Justin P. Mattock
@ 2009-10-07 13:00 ` Steven Rostedt
2009-10-07 14:53 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 13:00 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Tue, 2009-10-06 at 19:42 -0700, Justin P. Mattock wrote:
> >
> o.k. applied your patch, but unfortunantly
> I still am hitting this kernel panic.
>
> must admit I have no idea why this is doing this.
> (but am willing to sit through this, because eventually
> sooner or later will hit this if I update gcc).
But the panic you showed was that it could not find an init to execute.
Which looks like a setup issue and not a kernel bug.
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 2:02 ` Steven Rostedt
2009-10-07 2:42 ` Justin P. Mattock
@ 2009-10-07 14:30 ` Jason Baron
2009-10-07 14:40 ` Mathieu Desnoyers
1 sibling, 1 reply; 62+ messages in thread
From: Jason Baron @ 2009-10-07 14:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Justin Mattock, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List, mathieu.desnoyers
On Tue, Oct 06, 2009 at 10:02:01PM -0400, Steven Rostedt wrote:
> > So the problem I'm seeing is an oops on boot caused by the call->system pointer
> > deference in event_create_dir(). The 'call' variable is of type 'struct
> > ftrace_event_call'.
> >
> > What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> > (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> > structures are 16-byte aligned. Thus, the stride for walking through the
> > pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
> >
> > I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> > vanilla 2.6.31 kernel.
> >
> > That said, I'm not sure the compiler is doing the wrong thing here. The
> > 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> > is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> > minimum alignment for the variable or structure field, measured in bytes'.
> > Thus, at least according to the docs, gcc can increase the alignment of the
> > 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> > in the case where we are working corectly the structures are 8-byte aligned.
> >
> > Thus, I would reccommend the patch below as a preventive measure. Its
> > the minimal patch I've found to resolve this issue. In general, if we
> > are going to walk data structures embedded in a special elf section, I
> > think the general rules needs to be to set the alignment to the power of
> > two which is greater than or equal to the largest item in the structure.
> >
> > thanks,
> >
> > -Jason
> >
> > Signed-off-by: Jason Baron <jbaron@redhat.com>
> >
> >
> > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > index a81170d..7182f03 100644
> > --- a/include/linux/ftrace_event.h
> > +++ b/include/linux/ftrace_event.h
> > @@ -124,7 +124,10 @@ struct ftrace_event_call {
> > atomic_t profile_count;
> > int (*profile_enable)(struct ftrace_event_call *);
> > void (*profile_disable)(struct ftrace_event_call *);
> > -};
> > +} __attribute__((aligned(16)));
> > +
> > +/* Align to the largest field in the data structure:
> > + * sizeof(struct list_head) = 16 */
>
> Is this true for i386?
>
> I just tried this patch and it seems to work. Can you give it a try.
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index 4ec5e67..044b70d 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -133,7 +133,7 @@ struct ftrace_event_call {
> atomic_t profile_count;
> int (*profile_enable)(void);
> void (*profile_disable)(void);
> -};
> +} __attribute__((aligned(sizeof(struct list_head))));
>
> #define FTRACE_MAX_PROFILE_SIZE 2048
>
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index cc0d966..31e7637 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
> * }
> *
> * static struct ftrace_event_call __used
> - * __attribute__((__aligned__(4)))
> * __attribute__((section("_ftrace_events"))) event_<call> = {
> * .name = "<call>",
> * .system = "<system>",
> @@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
> } \
> \
> static struct ftrace_event_call __used \
> -__attribute__((__aligned__(4))) \
> __attribute__((section("_ftrace_events"))) event_##call = { \
> .name = #call, \
> .system = __stringify(TRACE_SYSTEM), \
>
>
indeed your patch works as well for me, its much cleaner!
However, I want to make sure this fix is sufficient and is the best way to
address this type of issue in general. For example, I know tracepoints are
using the aligned attribute in all 3 places -> definition, usage, and linker
alignment. (adding Mathieu to 'cc list). Is just the definition 'aligned'
sufficient? Also, once we find a method for solving these issues in general,
we need to review all users of this kind of technique to make sure they are
consistent. I also think your patch above needs to add a comment to say what
its doing.
thanks,
-Jason
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 14:30 ` Jason Baron
@ 2009-10-07 14:40 ` Mathieu Desnoyers
2009-10-07 14:55 ` Steven Rostedt
0 siblings, 1 reply; 62+ messages in thread
From: Mathieu Desnoyers @ 2009-10-07 14:40 UTC (permalink / raw)
To: Jason Baron
Cc: Steven Rostedt, Justin Mattock, Ingo Molnar, Peter Zijlstra,
Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
* Jason Baron (jbaron@redhat.com) wrote:
> On Tue, Oct 06, 2009 at 10:02:01PM -0400, Steven Rostedt wrote:
> > > So the problem I'm seeing is an oops on boot caused by the call->system pointer
> > > deference in event_create_dir(). The 'call' variable is of type 'struct
> > > ftrace_event_call'.
> > >
> > > What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> > > (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> > > structures are 16-byte aligned. Thus, the stride for walking through the
> > > pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
> > >
> > > I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> > > vanilla 2.6.31 kernel.
> > >
> > > That said, I'm not sure the compiler is doing the wrong thing here. The
> > > 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> > > is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> > > minimum alignment for the variable or structure field, measured in bytes'.
> > > Thus, at least according to the docs, gcc can increase the alignment of the
> > > 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> > > in the case where we are working corectly the structures are 8-byte aligned.
> > >
> > > Thus, I would reccommend the patch below as a preventive measure. Its
> > > the minimal patch I've found to resolve this issue. In general, if we
> > > are going to walk data structures embedded in a special elf section, I
> > > think the general rules needs to be to set the alignment to the power of
> > > two which is greater than or equal to the largest item in the structure.
> > >
> > > thanks,
> > >
> > > -Jason
> > >
> > > Signed-off-by: Jason Baron <jbaron@redhat.com>
> > >
> > >
> > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > > index a81170d..7182f03 100644
> > > --- a/include/linux/ftrace_event.h
> > > +++ b/include/linux/ftrace_event.h
> > > @@ -124,7 +124,10 @@ struct ftrace_event_call {
> > > atomic_t profile_count;
> > > int (*profile_enable)(struct ftrace_event_call *);
> > > void (*profile_disable)(struct ftrace_event_call *);
> > > -};
> > > +} __attribute__((aligned(16)));
> > > +
> > > +/* Align to the largest field in the data structure:
> > > + * sizeof(struct list_head) = 16 */
> >
> > Is this true for i386?
> >
> > I just tried this patch and it seems to work. Can you give it a try.
> >
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> >
> >
> > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > index 4ec5e67..044b70d 100644
> > --- a/include/linux/ftrace_event.h
> > +++ b/include/linux/ftrace_event.h
> > @@ -133,7 +133,7 @@ struct ftrace_event_call {
> > atomic_t profile_count;
> > int (*profile_enable)(void);
> > void (*profile_disable)(void);
> > -};
> > +} __attribute__((aligned(sizeof(struct list_head))));
I don't like that.
Basically, the vmlinux.lds.h linker script must have alignment
statements before each section, which match the alignment of the section
structures. Failure to do so would put padding at the beginning of the
section, which is definitely not working at all. I don't see how we can
automatically pass sizeof(struct list_head) to a linker script :/
Mathieu
> >
> > #define FTRACE_MAX_PROFILE_SIZE 2048
> >
> > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > index cc0d966..31e7637 100644
> > --- a/include/trace/ftrace.h
> > +++ b/include/trace/ftrace.h
> > @@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
> > * }
> > *
> > * static struct ftrace_event_call __used
> > - * __attribute__((__aligned__(4)))
> > * __attribute__((section("_ftrace_events"))) event_<call> = {
> > * .name = "<call>",
> > * .system = "<system>",
> > @@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
> > } \
> > \
> > static struct ftrace_event_call __used \
> > -__attribute__((__aligned__(4))) \
> > __attribute__((section("_ftrace_events"))) event_##call = { \
> > .name = #call, \
> > .system = __stringify(TRACE_SYSTEM), \
> >
> >
>
> indeed your patch works as well for me, its much cleaner!
>
> However, I want to make sure this fix is sufficient and is the best way to
> address this type of issue in general. For example, I know tracepoints are
> using the aligned attribute in all 3 places -> definition, usage, and linker
> alignment. (adding Mathieu to 'cc list). Is just the definition 'aligned'
> sufficient? Also, once we find a method for solving these issues in general,
> we need to review all users of this kind of technique to make sure they are
> consistent. I also think your patch above needs to add a comment to say what
> its doing.
>
> thanks,
>
> -Jason
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 13:00 ` Steven Rostedt
@ 2009-10-07 14:53 ` Justin P. Mattock
2009-10-07 15:11 ` Steven Rostedt
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 14:53 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Tue, 2009-10-06 at 19:42 -0700, Justin P. Mattock wrote:
>
>
>>>
>>>
>> o.k. applied your patch, but unfortunantly
>> I still am hitting this kernel panic.
>>
>> must admit I have no idea why this is doing this.
>> (but am willing to sit through this, because eventually
>> sooner or later will hit this if I update gcc).
>>
>
> But the panic you showed was that it could not find an init to execute.
> Which looks like a setup issue and not a kernel bug.
>
> -- Steve
>
>
>
>
That's whats getting me, i.g. if I compile
sysvinit normally without adding an SELinux patch
the system boots, as soon as I compile sysvinit with
SELinux support to load the policy, bam... I hit this.
I can send a post to SELinux and see what they think,
and the go from there.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 14:40 ` Mathieu Desnoyers
@ 2009-10-07 14:55 ` Steven Rostedt
2009-10-07 15:05 ` Mathieu Desnoyers
0 siblings, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 14:55 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Jason Baron, Justin Mattock, Ingo Molnar, Peter Zijlstra,
Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
On Wed, 2009-10-07 at 10:40 -0400, Mathieu Desnoyers wrote:
> * Jason Baron (jbaron@redhat.com) wrote:
> > On Tue, Oct 06, 2009 at 10:02:01PM -0400, Steven Rostedt wrote:
> > > > So the problem I'm seeing is an oops on boot caused by the call->system pointer
> > > > deference in event_create_dir(). The 'call' variable is of type 'struct
> > > > ftrace_event_call'.
> > > >
> > > > What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> > > > (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> > > > structures are 16-byte aligned. Thus, the stride for walking through the
> > > > pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
> > > >
> > > > I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> > > > vanilla 2.6.31 kernel.
> > > >
> > > > That said, I'm not sure the compiler is doing the wrong thing here. The
> > > > 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> > > > is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> > > > minimum alignment for the variable or structure field, measured in bytes'.
> > > > Thus, at least according to the docs, gcc can increase the alignment of the
> > > > 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> > > > in the case where we are working corectly the structures are 8-byte aligned.
> > > >
> > > > Thus, I would reccommend the patch below as a preventive measure. Its
> > > > the minimal patch I've found to resolve this issue. In general, if we
> > > > are going to walk data structures embedded in a special elf section, I
> > > > think the general rules needs to be to set the alignment to the power of
> > > > two which is greater than or equal to the largest item in the structure.
> > > >
> > > > thanks,
> > > >
> > > > -Jason
> > > >
> > > > Signed-off-by: Jason Baron <jbaron@redhat.com>
> > > >
> > > >
> > > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > > > index a81170d..7182f03 100644
> > > > --- a/include/linux/ftrace_event.h
> > > > +++ b/include/linux/ftrace_event.h
> > > > @@ -124,7 +124,10 @@ struct ftrace_event_call {
> > > > atomic_t profile_count;
> > > > int (*profile_enable)(struct ftrace_event_call *);
> > > > void (*profile_disable)(struct ftrace_event_call *);
> > > > -};
> > > > +} __attribute__((aligned(16)));
> > > > +
> > > > +/* Align to the largest field in the data structure:
> > > > + * sizeof(struct list_head) = 16 */
> > >
> > > Is this true for i386?
> > >
> > > I just tried this patch and it seems to work. Can you give it a try.
> > >
> > > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > >
> > >
> > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > > index 4ec5e67..044b70d 100644
> > > --- a/include/linux/ftrace_event.h
> > > +++ b/include/linux/ftrace_event.h
> > > @@ -133,7 +133,7 @@ struct ftrace_event_call {
> > > atomic_t profile_count;
> > > int (*profile_enable)(void);
> > > void (*profile_disable)(void);
> > > -};
> > > +} __attribute__((aligned(sizeof(struct list_head))));
>
> I don't like that.
>
> Basically, the vmlinux.lds.h linker script must have alignment
> statements before each section, which match the alignment of the section
> structures. Failure to do so would put padding at the beginning of the
> section, which is definitely not working at all. I don't see how we can
> automatically pass sizeof(struct list_head) to a linker script :/
OK, what about __attribute__((aligned((BITS_PER_LONG/8)*2)))
That should also work in the linker script as well.
With the added comment:
/*
* We must aligned by the largest item in the structure. This happens
* to be the list_head, which consists of two pointers.
*/
>
> Mathieu
>
> > >
> > > #define FTRACE_MAX_PROFILE_SIZE 2048
> > >
> > > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > > index cc0d966..31e7637 100644
> > > --- a/include/trace/ftrace.h
> > > +++ b/include/trace/ftrace.h
> > > @@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
> > > * }
> > > *
> > > * static struct ftrace_event_call __used
> > > - * __attribute__((__aligned__(4)))
> > > * __attribute__((section("_ftrace_events"))) event_<call> = {
> > > * .name = "<call>",
> > > * .system = "<system>",
> > > @@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
> > > } \
> > > \
> > > static struct ftrace_event_call __used \
> > > -__attribute__((__aligned__(4))) \
> > > __attribute__((section("_ftrace_events"))) event_##call = { \
> > > .name = #call, \
> > > .system = __stringify(TRACE_SYSTEM), \
> > >
> > >
> >
> > indeed your patch works as well for me, its much cleaner!
> >
> > However, I want to make sure this fix is sufficient and is the best way to
> > address this type of issue in general. For example, I know tracepoints are
> > using the aligned attribute in all 3 places -> definition, usage, and linker
> > alignment. (adding Mathieu to 'cc list). Is just the definition 'aligned'
> > sufficient? Also, once we find a method for solving these issues in general,
> > we need to review all users of this kind of technique to make sure they are
> > consistent. I also think your patch above needs to add a comment to say what
> > its doing.
Yes, I forgot to add the comment. One really does belong there.
-- Steve
> >
> > thanks,
> >
> > -Jason
> >
> >
>
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 14:55 ` Steven Rostedt
@ 2009-10-07 15:05 ` Mathieu Desnoyers
2009-10-07 15:14 ` Steven Rostedt
0 siblings, 1 reply; 62+ messages in thread
From: Mathieu Desnoyers @ 2009-10-07 15:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jason Baron, Justin Mattock, Ingo Molnar, Peter Zijlstra,
Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Wed, 2009-10-07 at 10:40 -0400, Mathieu Desnoyers wrote:
> > * Jason Baron (jbaron@redhat.com) wrote:
> > > On Tue, Oct 06, 2009 at 10:02:01PM -0400, Steven Rostedt wrote:
> > > > > So the problem I'm seeing is an oops on boot caused by the call->system pointer
> > > > > deference in event_create_dir(). The 'call' variable is of type 'struct
> > > > > ftrace_event_call'.
> > > > >
> > > > > What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
> > > > > (sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
> > > > > structures are 16-byte aligned. Thus, the stride for walking through the
> > > > > pointers needs to be 176 (0xB0), but instead its 168 causing the oops.
> > > > >
> > > > > I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
> > > > > vanilla 2.6.31 kernel.
> > > > >
> > > > > That said, I'm not sure the compiler is doing the wrong thing here. The
> > > > > 'struct ftrace_event_call' contains an embedded 'struct list_head' which
> > > > > is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
> > > > > minimum alignment for the variable or structure field, measured in bytes'.
> > > > > Thus, at least according to the docs, gcc can increase the alignment of the
> > > > > 'struct ftrace_event_call', from its original specification of 4, to 16. Even
> > > > > in the case where we are working corectly the structures are 8-byte aligned.
> > > > >
> > > > > Thus, I would reccommend the patch below as a preventive measure. Its
> > > > > the minimal patch I've found to resolve this issue. In general, if we
> > > > > are going to walk data structures embedded in a special elf section, I
> > > > > think the general rules needs to be to set the alignment to the power of
> > > > > two which is greater than or equal to the largest item in the structure.
> > > > >
> > > > > thanks,
> > > > >
> > > > > -Jason
> > > > >
> > > > > Signed-off-by: Jason Baron <jbaron@redhat.com>
> > > > >
> > > > >
> > > > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > > > > index a81170d..7182f03 100644
> > > > > --- a/include/linux/ftrace_event.h
> > > > > +++ b/include/linux/ftrace_event.h
> > > > > @@ -124,7 +124,10 @@ struct ftrace_event_call {
> > > > > atomic_t profile_count;
> > > > > int (*profile_enable)(struct ftrace_event_call *);
> > > > > void (*profile_disable)(struct ftrace_event_call *);
> > > > > -};
> > > > > +} __attribute__((aligned(16)));
> > > > > +
> > > > > +/* Align to the largest field in the data structure:
> > > > > + * sizeof(struct list_head) = 16 */
> > > >
> > > > Is this true for i386?
> > > >
> > > > I just tried this patch and it seems to work. Can you give it a try.
> > > >
> > > > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > > >
> > > >
> > > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > > > index 4ec5e67..044b70d 100644
> > > > --- a/include/linux/ftrace_event.h
> > > > +++ b/include/linux/ftrace_event.h
> > > > @@ -133,7 +133,7 @@ struct ftrace_event_call {
> > > > atomic_t profile_count;
> > > > int (*profile_enable)(void);
> > > > void (*profile_disable)(void);
> > > > -};
> > > > +} __attribute__((aligned(sizeof(struct list_head))));
> >
> > I don't like that.
> >
> > Basically, the vmlinux.lds.h linker script must have alignment
> > statements before each section, which match the alignment of the section
> > structures. Failure to do so would put padding at the beginning of the
> > section, which is definitely not working at all. I don't see how we can
> > automatically pass sizeof(struct list_head) to a linker script :/
>
> OK, what about __attribute__((aligned((BITS_PER_LONG/8)*2)))
>
> That should also work in the linker script as well.
>
> With the added comment:
>
> /*
> * We must aligned by the largest item in the structure. This happens
> * to be the list_head, which consists of two pointers.
> */
>
Yep, sounds good. Oddly we have to keep these in sync manually. I'd also
add a comment in the C code to tell whoever want to change the size of
the structure to also check the linker script.
Also adding a BUILD_BUG_ON() that checks the structure sizeof() would be
a nice safety-net (this should probably be added to tracepoints too
eventually).
Mathieu
> >
> > Mathieu
> >
> > > >
> > > > #define FTRACE_MAX_PROFILE_SIZE 2048
> > > >
> > > > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > > > index cc0d966..31e7637 100644
> > > > --- a/include/trace/ftrace.h
> > > > +++ b/include/trace/ftrace.h
> > > > @@ -501,7 +501,6 @@ static void ftrace_profile_disable_##call(void) \
> > > > * }
> > > > *
> > > > * static struct ftrace_event_call __used
> > > > - * __attribute__((__aligned__(4)))
> > > > * __attribute__((section("_ftrace_events"))) event_<call> = {
> > > > * .name = "<call>",
> > > > * .system = "<system>",
> > > > @@ -619,7 +618,6 @@ static int ftrace_raw_init_event_##call(void) \
> > > > } \
> > > > \
> > > > static struct ftrace_event_call __used \
> > > > -__attribute__((__aligned__(4))) \
> > > > __attribute__((section("_ftrace_events"))) event_##call = { \
> > > > .name = #call, \
> > > > .system = __stringify(TRACE_SYSTEM), \
> > > >
> > > >
> > >
> > > indeed your patch works as well for me, its much cleaner!
> > >
> > > However, I want to make sure this fix is sufficient and is the best way to
> > > address this type of issue in general. For example, I know tracepoints are
> > > using the aligned attribute in all 3 places -> definition, usage, and linker
> > > alignment. (adding Mathieu to 'cc list). Is just the definition 'aligned'
> > > sufficient? Also, once we find a method for solving these issues in general,
> > > we need to review all users of this kind of technique to make sure they are
> > > consistent. I also think your patch above needs to add a comment to say what
> > > its doing.
>
> Yes, I forgot to add the comment. One really does belong there.
>
> -- Steve
>
> > >
> > > thanks,
> > >
> > > -Jason
> > >
> > >
> >
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 14:53 ` Justin P. Mattock
@ 2009-10-07 15:11 ` Steven Rostedt
2009-10-07 15:52 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 15:11 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Wed, 2009-10-07 at 07:53 -0700, Justin P. Mattock wrote:
> Steven Rostedt wrote:
> > On Tue, 2009-10-06 at 19:42 -0700, Justin P. Mattock wrote:
> >
> >
> >>>
> >>>
> >> o.k. applied your patch, but unfortunantly
> >> I still am hitting this kernel panic.
> >>
> >> must admit I have no idea why this is doing this.
> >> (but am willing to sit through this, because eventually
> >> sooner or later will hit this if I update gcc).
> >>
> >
> > But the panic you showed was that it could not find an init to execute.
> > Which looks like a setup issue and not a kernel bug.
> >
> > -- Steve
> >
> >
> >
> >
> That's whats getting me, i.g. if I compile
> sysvinit normally without adding an SELinux patch
> the system boots, as soon as I compile sysvinit with
> SELinux support to load the policy, bam... I hit this.
>
> I can send a post to SELinux and see what they think,
> and the go from there.
Oh! It's an SELinux thing. It probably prevents you from executing
init ;-)
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 15:05 ` Mathieu Desnoyers
@ 2009-10-07 15:14 ` Steven Rostedt
0 siblings, 0 replies; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 15:14 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Jason Baron, Justin Mattock, Ingo Molnar, Peter Zijlstra,
Li Zefan, Frederic Weisbecker, Linux Kernel Mailing List
On Wed, 2009-10-07 at 11:05 -0400, Mathieu Desnoyers wrote:
> Also adding a BUILD_BUG_ON() that checks the structure sizeof() would be
> a nice safety-net (this should probably be added to tracepoints too
> eventually).
Yeah, I was thinking the same thing. But that would have to be added
somewhere in a C file.
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 15:11 ` Steven Rostedt
@ 2009-10-07 15:52 ` Justin P. Mattock
2009-10-07 16:06 ` Steven Rostedt
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 15:52 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Wed, 2009-10-07 at 07:53 -0700, Justin P. Mattock wrote:
>
>> Steven Rostedt wrote:
>>
>>> On Tue, 2009-10-06 at 19:42 -0700, Justin P. Mattock wrote:
>>>
>>>
>>>
>>>>>
>>>>>
>>>> o.k. applied your patch, but unfortunantly
>>>> I still am hitting this kernel panic.
>>>>
>>>> must admit I have no idea why this is doing this.
>>>> (but am willing to sit through this, because eventually
>>>> sooner or later will hit this if I update gcc).
>>>>
>>>>
>>> But the panic you showed was that it could not find an init to execute.
>>> Which looks like a setup issue and not a kernel bug.
>>>
>>> -- Steve
>>>
>>>
>>>
>>>
>>>
>> That's whats getting me, i.g. if I compile
>> sysvinit normally without adding an SELinux patch
>> the system boots, as soon as I compile sysvinit with
>> SELinux support to load the policy, bam... I hit this.
>>
>> I can send a post to SELinux and see what they think,
>> and the go from there.
>>
>
> Oh! It's an SELinux thing. It probably prevents you from executing
> init ;-)
>
> -- Steve
>
>
>
>
What I think is happening is while building
sysvinit with the SELinux patch, sysvinit is looking
in /lib for libselinux(but could be wrong) but libselinux is in
/lib64.
(here's my excuse as a newbie:)
part of a pain when building an x86_64 multilib is building
everything to point to lib64(pure64 with the soft link
lib64 -> lib makes life so much easier).
I'm going to look at that patch and see how it tells
-lselinux -lsepol to find the libs.
(if this is the case then I must admit I am a real
newbie, and apologize for the confusion).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 15:52 ` Justin P. Mattock
@ 2009-10-07 16:06 ` Steven Rostedt
2009-10-07 17:47 ` Justin P. Mattock
2009-10-07 18:45 ` Justin P. Mattock
0 siblings, 2 replies; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 16:06 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Wed, 2009-10-07 at 08:52 -0700, Justin P. Mattock wrote:
> >
> What I think is happening is while building
> sysvinit with the SELinux patch, sysvinit is looking
> in /lib for libselinux(but could be wrong) but libselinux is in
> /lib64.
> (here's my excuse as a newbie:)
> part of a pain when building an x86_64 multilib is building
> everything to point to lib64(pure64 with the soft link
> lib64 -> lib makes life so much easier).
>
> I'm going to look at that patch and see how it tells
> -lselinux -lsepol to find the libs.
> (if this is the case then I must admit I am a real
> newbie, and apologize for the confusion).
Justin,
Just being able to monkey around with the init code on top of SELinux
already qualifies you to be well beyond a newbie ;-)
-- Steve
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 16:06 ` Steven Rostedt
@ 2009-10-07 17:47 ` Justin P. Mattock
2009-10-07 18:45 ` Justin P. Mattock
1 sibling, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 17:47 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Wed, 2009-10-07 at 08:52 -0700, Justin P. Mattock wrote:
>
>
>>>
>>>
>> What I think is happening is while building
>> sysvinit with the SELinux patch, sysvinit is looking
>> in /lib for libselinux(but could be wrong) but libselinux is in
>> /lib64.
>> (here's my excuse as a newbie:)
>> part of a pain when building an x86_64 multilib is building
>> everything to point to lib64(pure64 with the soft link
>> lib64 -> lib makes life so much easier).
>>
>> I'm going to look at that patch and see how it tells
>> -lselinux -lsepol to find the libs.
>> (if this is the case then I must admit I am a real
>> newbie, and apologize for the confusion).
>>
>
> Justin,
>
> Just being able to monkey around with the init code on top of SELinux
> already qualifies you to be well beyond a newbie ;-)
>
> -- Steve
>
>
>
>
Thanks man!!(I really appreciate that).
Im looking at sysvinit right now
Im thinking all it really needs is
LIBDIR/LDFLAGS=-L/lib64 -lselinux -lsepol
in the Makefile or something in that area.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 16:06 ` Steven Rostedt
2009-10-07 17:47 ` Justin P. Mattock
@ 2009-10-07 18:45 ` Justin P. Mattock
2009-10-07 18:55 ` Steven Rostedt
1 sibling, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 18:45 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Wed, 2009-10-07 at 08:52 -0700, Justin P. Mattock wrote:
>
>
>>>
>>>
>> What I think is happening is while building
>> sysvinit with the SELinux patch, sysvinit is looking
>> in /lib for libselinux(but could be wrong) but libselinux is in
>> /lib64.
>> (here's my excuse as a newbie:)
>> part of a pain when building an x86_64 multilib is building
>> everything to point to lib64(pure64 with the soft link
>> lib64 -> lib makes life so much easier).
>>
>> I'm going to look at that patch and see how it tells
>> -lselinux -lsepol to find the libs.
>> (if this is the case then I must admit I am a real
>> newbie, and apologize for the confusion).
>>
>
> Justin,
>
> Just being able to monkey around with the init code on top of SELinux
> already qualifies you to be well beyond a newbie ;-)
>
> -- Steve
>
>
>
>
yep like I said I owe you guys an apology, for
my mistake(thanks for taking the time).
From what it looks like init was looking for libselinux
in /lib instead of /lib64.
after adjusting the Makefile and adding:
LDFLAGS = -s -L/lib64 -lselinux -lsepol
LIBDIR=/lib64
the system boots right up.
(sh*t built everything to point to lib64(xserver and all).., and
forgot the modify init.c to do the same).
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 18:45 ` Justin P. Mattock
@ 2009-10-07 18:55 ` Steven Rostedt
2009-10-07 19:08 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Steven Rostedt @ 2009-10-07 18:55 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
On Wed, 2009-10-07 at 11:45 -0700, Justin P. Mattock wrote:
> >
> yep like I said I owe you guys an apology, for
> my mistake(thanks for taking the time).
Well, thank you for reporting it. If nobody reports any problems, we
just assume everything is OK, and as people curse us out and look for
alternatives, we will be sipping our mai-tais in ignorant bliss.
-- Steve
>
> From what it looks like init was looking for libselinux
> in /lib instead of /lib64.
> after adjusting the Makefile and adding:
> LDFLAGS = -s -L/lib64 -lselinux -lsepol
> LIBDIR=/lib64
> the system boots right up.
> (sh*t built everything to point to lib64(xserver and all).., and
> forgot the modify init.c to do the same).
>
> Justin P. Mattock
>
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 18:55 ` Steven Rostedt
@ 2009-10-07 19:08 ` Justin P. Mattock
2009-10-12 10:17 ` Ingo Molnar
0 siblings, 1 reply; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-07 19:08 UTC (permalink / raw)
To: rostedt
Cc: Jason Baron, Ingo Molnar, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Steven Rostedt wrote:
> On Wed, 2009-10-07 at 11:45 -0700, Justin P. Mattock wrote:
>
>
>>>
>>>
>> yep like I said I owe you guys an apology, for
>> my mistake(thanks for taking the time).
>>
>
> Well, thank you for reporting it. If nobody reports any problems, we
> just assume everything is OK, and as people curse us out and look for
> alternatives, we will be sipping our mai-tais in ignorant bliss.
>
> -- Steve
>
>
agree,
my main concern when reporting is to make sure
that it's a real issue, and not a mistake like this one.
Anyways, a mai-tais sure does sound good
(sign me up!!)
>> From what it looks like init was looking for libselinux
>> in /lib instead of /lib64.
>> after adjusting the Makefile and adding:
>> LDFLAGS = -s -L/lib64 -lselinux -lsepol
>> LIBDIR=/lib64
>> the system boots right up.
>> (sh*t built everything to point to lib64(xserver and all).., and
>> forgot the modify init.c to do the same).
>>
>> Justin P. Mattock
>>
>>
>
>
>
Justin P. mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-07 19:08 ` Justin P. Mattock
@ 2009-10-12 10:17 ` Ingo Molnar
2009-10-12 18:16 ` Justin P. Mattock
0 siblings, 1 reply; 62+ messages in thread
From: Ingo Molnar @ 2009-10-12 10:17 UTC (permalink / raw)
To: Justin P. Mattock
Cc: rostedt, Jason Baron, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
* Justin P. Mattock <justinmattock@gmail.com> wrote:
> Steven Rostedt wrote:
>> On Wed, 2009-10-07 at 11:45 -0700, Justin P. Mattock wrote:
>>
>>
>>>>
>>>>
>>> yep like I said I owe you guys an apology, for
>>> my mistake(thanks for taking the time).
>>>
>>
>> Well, thank you for reporting it. If nobody reports any problems, we
>> just assume everything is OK, and as people curse us out and look for
>> alternatives, we will be sipping our mai-tais in ignorant bliss.
>>
>> -- Steve
>>
>>
>
> agree, my main concern when reporting is to make sure that it's a real
> issue, and not a mistake like this one.
Well, it can be really hard to filter out whether a problem is somehow
self-inflicted or caused by the kernel proper - thus we generally prefer
over-reporting over under-reporting.
Even if it's self-inflicted it's useful on a meta level: if many people
report it then we might end up adding more safety guards to disable a
particular common pattern of shoot-foot-self incidents.
Ingo
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: system gets stuck in a lock during boot
2009-10-12 10:17 ` Ingo Molnar
@ 2009-10-12 18:16 ` Justin P. Mattock
0 siblings, 0 replies; 62+ messages in thread
From: Justin P. Mattock @ 2009-10-12 18:16 UTC (permalink / raw)
To: Ingo Molnar
Cc: rostedt, Jason Baron, Peter Zijlstra, Li Zefan,
Frederic Weisbecker, Linux Kernel Mailing List
Ingo Molnar wrote:
> * Justin P. Mattock<justinmattock@gmail.com> wrote:
>
>
>> Steven Rostedt wrote:
>>
>>> On Wed, 2009-10-07 at 11:45 -0700, Justin P. Mattock wrote:
>>>
>>>
>>>
>>>>>
>>>>>
>>>> yep like I said I owe you guys an apology, for
>>>> my mistake(thanks for taking the time).
>>>>
>>>>
>>> Well, thank you for reporting it. If nobody reports any problems, we
>>> just assume everything is OK, and as people curse us out and look for
>>> alternatives, we will be sipping our mai-tais in ignorant bliss.
>>>
>>> -- Steve
>>>
>>>
>>>
>> agree, my main concern when reporting is to make sure that it's a real
>> issue, and not a mistake like this one.
>>
>
> Well, it can be really hard to filter out whether a problem is somehow
> self-inflicted or caused by the kernel proper - thus we generally prefer
> over-reporting over under-reporting.
>
> Even if it's self-inflicted it's useful on a meta level: if many people
> report it then we might end up adding more safety guards to disable a
> particular common pattern of shoot-foot-self incidents.
>
> Ingo
>
>
CONFIG_INGO=y
Thanks man, yeah I agree the more over reporting the better.
but in this case I did shoot myself in the foot(not by choice though).
In any case I really appreciate all of you guys
taking the time to look at this. I will try and be more careful the
next time in reporting.
Justin P. Mattock
^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2009-10-12 18:17 UTC | newest]
Thread overview: 62+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-13 15:42 system gets stuck in a lock during boot Justin P. Mattock
2009-08-18 10:49 ` Frederic Weisbecker
2009-08-18 16:09 ` Steven Rostedt
2009-08-18 16:24 ` Justin Mattock
2009-08-18 19:57 ` Steven Rostedt
2009-08-18 20:06 ` Justin P. Mattock
2009-08-18 23:29 ` Steven Rostedt
2009-08-18 23:55 ` Justin P. Mattock
2009-08-19 0:23 ` Justin P. Mattock
2009-08-19 0:31 ` Steven Rostedt
2009-08-19 1:18 ` Justin P. Mattock
2009-08-19 1:10 ` Li Zefan
2009-08-20 5:51 ` Justin P. Mattock
2009-08-22 7:48 ` Justin P. Mattock
2009-08-24 2:41 ` Li Zefan
2009-08-24 3:07 ` Justin P. Mattock
2009-08-24 5:58 ` Peter Zijlstra
2009-08-24 6:13 ` Li Zefan
2009-08-24 6:49 ` Justin P. Mattock
2009-08-24 6:55 ` Peter Zijlstra
2009-08-24 7:54 ` Justin P. Mattock
2009-08-24 8:40 ` Justin P. Mattock
2009-08-24 19:19 ` Justin Mattock
2009-08-25 5:50 ` Peter Zijlstra
2009-08-25 6:04 ` Li Zefan
2009-08-25 6:21 ` Peter Zijlstra
2009-08-25 8:59 ` Ingo Molnar
2009-08-26 0:22 ` Justin P. Mattock
2009-08-26 7:33 ` Ingo Molnar
2009-08-26 14:42 ` Justin P. Mattock
2009-09-07 21:49 ` Justin Mattock
2009-10-02 21:12 ` Jason Baron
2009-10-04 17:41 ` Ingo Molnar
2009-10-05 0:10 ` Justin Mattock
2009-10-06 1:00 ` Justin P. Mattock
2009-10-06 1:18 ` Steven Rostedt
2009-10-06 2:01 ` Justin P. Mattock
2009-10-06 14:31 ` Jason Baron
2009-10-06 15:12 ` Justin P. Mattock
2009-10-06 1:24 ` Steven Rostedt
2009-10-06 20:32 ` Jason Baron
2009-10-06 22:30 ` Justin P. Mattock
2009-10-07 2:02 ` Steven Rostedt
2009-10-07 2:42 ` Justin P. Mattock
2009-10-07 13:00 ` Steven Rostedt
2009-10-07 14:53 ` Justin P. Mattock
2009-10-07 15:11 ` Steven Rostedt
2009-10-07 15:52 ` Justin P. Mattock
2009-10-07 16:06 ` Steven Rostedt
2009-10-07 17:47 ` Justin P. Mattock
2009-10-07 18:45 ` Justin P. Mattock
2009-10-07 18:55 ` Steven Rostedt
2009-10-07 19:08 ` Justin P. Mattock
2009-10-12 10:17 ` Ingo Molnar
2009-10-12 18:16 ` Justin P. Mattock
2009-10-07 14:30 ` Jason Baron
2009-10-07 14:40 ` Mathieu Desnoyers
2009-10-07 14:55 ` Steven Rostedt
2009-10-07 15:05 ` Mathieu Desnoyers
2009-10-07 15:14 ` Steven Rostedt
2009-08-24 19:42 ` Steven Rostedt
2009-08-24 23:34 ` Justin Mattock
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).