2008-08-03 20:11:44

by Frans Pop

[permalink] [raw]
Subject: [regression?] usb: new errors during device detection

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.27-rc1
# Thu Jul 31 18:02:41 2008
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
# CONFIG_GENERIC_LOCKBREAK is not set
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_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 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_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_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_AOUT=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# 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 is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_SYSCALL_CHECK=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_COMPAT_BRK is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_MARKERS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_ARCH_TRACEHOOK is not set
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_USE_GENERIC_SMP_HELPERS=y
# CONFIG_HAVE_CLK is not set
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
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_CLASSIC_RCU=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_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_VSMP is not set
# 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_MWINCHIP2 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=128
CONFIG_X86_INTERNODE_CACHE_BYTES=128
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
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_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=6
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_GET_USER_PAGES_FAST=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
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_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y

#
# Power management 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=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=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_WMI is not set
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
CONFIG_ACPI_SBS=m

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE 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=m
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=m
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
CONFIG_HOTPLUG_PCI_SHPC=m

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
# 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 is not set
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=y
# CONFIG_ARPD is not set
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=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
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=y
# 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 is not set
CONFIG_DEFAULT_TCP_CONG="bic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IP_VS=m
# 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_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=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=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 is not set
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
# CONFIG_NF_CT_PROTO_UDPLITE is not set
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_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=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_HELPER=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_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=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_SCTP=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_HASHLIMIT=m

#
# IP: Netfilter Configuration
#
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_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_ADDRTYPE=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_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=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_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=m
# CONFIG_IP_NF_SECURITY is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m
# CONFIG_IP6_NF_SECURITY is not set

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
# CONFIG_BRIDGE_EBT_IP6 is not set
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
# CONFIG_BRIDGE_EBT_NFLOG is not set
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=m
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_DCCP_TFRC_LIB=m

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# 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_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_FLOW is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
CONFIG_RXKAD=m
CONFIG_FIB_RULES=y

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
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=m
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
CONFIG_MTD_SBC_GXX=m
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_ESB2ROM is not set
# CONFIG_MTD_CK804XROM is not set
# CONFIG_MTD_SCB2_FLASH is not set
CONFIG_MTD_NETtel=m
CONFIG_MTD_DILNETPC=m
CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000
# CONFIG_MTD_L440GX is not set
CONFIG_MTD_PCI=m
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=m

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
CONFIG_MTD_SLRAM=m
CONFIG_MTD_PHRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCECC=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
CONFIG_MTD_NAND_CAFE=m
# CONFIG_MTD_NAND_NANDSIM is not set
CONFIG_MTD_NAND_PLATFORM=m
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_ONENAND=m
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set

#
# UBI - Unsorted block images
#
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set

#
# UBI debugging options
#
# CONFIG_MTD_UBI_DEBUG is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=m
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
# CONFIG_PARIDE_EPATC8 is not set
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
# CONFIG_BLK_CPQ_DA is not set
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_ATAPI=y
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPNP=m
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=m
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

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

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_FC_TGT_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=m
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=m
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# 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 is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_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=m
# 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 is not set
# 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=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_DELAY=m
# CONFIG_DM_UEVENT is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
CONFIG_EQUALIZER=m
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_MII=m
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_E1000E=m
# CONFIG_IP1000 is not set
# CONFIG_IGB 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 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E 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 is not set
# CONFIG_IWLWIFI_LEDS is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
# CONFIG_USB_HSO is not set
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=m
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
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 is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m

#
# 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_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
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_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA 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=m
# 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_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX 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=m
# 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_UINPUT=m

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

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
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_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_NVRAM=m
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=m

#
# I2C Hardware Bus support
#

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

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

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
CONFIG_I2C_VOODOO3=m

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

#
# Miscellaneous I2C Chip support
#
CONFIG_DS1682=m
# CONFIG_AT24 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
CONFIG_SENSORS_TSL2550=m
# 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
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7473=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_FSCHMD=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_CORETEMP=m
# CONFIG_SENSORS_IBMAEM is not set
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
# CONFIG_SENSORS_ADS7828 is not set
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
# CONFIG_SENSORS_W83L786NG is not set
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
CONFIG_I6300ESB_WDT=m
CONFIG_ITCO_WDT=m
# CONFIG_ITCO_VENDOR_SUPPORT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_HP_WATCHDOG is not set
CONFIG_SC1200_WDT=m
CONFIG_PC87413_WDT=m
CONFIG_60XX_WDT=m
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_SMSC37B787_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_SBC_EPX_C3_WATCHDOG=m

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# 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

#
# Multimedia devices
#

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

#
# Multimedia drivers
#
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=m
# 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_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
# 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=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
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 is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# 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_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
CONFIG_BACKLIGHT_PROGEAR=m
# CONFIG_BACKLIGHT_MBP_NVIDIA 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 is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# 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_DRIVERS is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_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_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_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 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_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# 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_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 is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT_POWERBOOK=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
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=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_R8A66597_HCD is not set

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

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
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_DPCM is not set
CONFIG_USB_STORAGE_USBAT=y
# 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
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=m
# 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_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET 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=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=m
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m

#
# LED drivers
#
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

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

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=m
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
# 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_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
# CONFIG_REISERFS_FS is not set
# 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_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
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_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_ECRYPT_FS=m
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_UBIFS_FS is not set
# CONFIG_CRAMFS 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=m
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# 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_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

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

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
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_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_OBJECTS=y
# CONFIG_DEBUG_OBJECTS_SELFTEST is not set
# CONFIG_DEBUG_OBJECTS_FREE is not set
# CONFIG_DEBUG_OBJECTS_TIMERS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# 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_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
# CONFIG_FTRACE is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DIRECT_GBPAGES is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_MMIOTRACE is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m

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

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
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_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
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 is not set
# 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=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y


Attachments:
(No filename) (2.35 kB)
2.6.27-rc1 (32.60 kB)
config-2.6.27-rc1 (59.31 kB)
Download all attachments

2008-08-03 20:35:32

by Felipe Balbi

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

Hi,

On Sun, Aug 03, 2008 at 10:11:21PM +0200, Frans Pop wrote:
> +usb 3-1: new low speed USB device using uhci_hcd and address 2
> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> usb usb5: configuration #1 chosen from 1 choice
> hub 5-0:1.0: USB hub found
> -usb 3-1: new low speed USB device using uhci_hcd and address 2
> +usb 3-1: device not accepting address 2, error -71
> +hub 3-0:1.0: unable to enumerate USB device on port 1

what is this device attached to this port ?

Do you have the device attached before turning on the machine ?
Does it happen if you boot without that device attached and attach
it afterwards ?

Can you please enable CONFIG_USB_DEBUG and resend dmesg output ?

thanks,

--
balbi

2008-08-04 14:14:29

by Alan Stern

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Sun, 3 Aug 2008, Frans Pop wrote:

> Not sure how I should interpret this difference between dmesg output for
> 2.6.26 and 2.6.27-rc1 (after 'grep -i usb'):
>
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> USB Universal Host Controller Interface driver v3.0
> uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
> uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
> usb usb3: configuration #1 chosen from 1 choice
> hub 3-0:1.0: USB hub found
> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
> usb usb4: configuration #1 chosen from 1 choice
> hub 4-0:1.0: USB hub found
> +usb 3-1: new low speed USB device using uhci_hcd and address 2
> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> usb usb5: configuration #1 chosen from 1 choice
> hub 5-0:1.0: USB hub found
> -usb 3-1: new low speed USB device using uhci_hcd and address 2
> +usb 3-1: device not accepting address 2, error -71
> +hub 3-0:1.0: unable to enumerate USB device on port 1
> +usb 3-1: new low speed USB device using uhci_hcd and address 4
> usb 3-1: configuration #1 chosen from 1 choice
> usb 4-1: new low speed USB device using uhci_hcd and address 2
> usb 4-1: configuration #1 chosen from 1 choice
> usbcore: registered new interface driver hiddev
> input: USB Compliant Keyboard as /class/input/input0
> input: USB HID v1.10 Keyboard [USB Compliant Keyboard] on usb-0000:00:1d.2-1
> input: USB Compliant Keyboard as /class/input/input1
> input: USB HID v1.10 Device [USB Compliant Keyboard] on usb-0000:00:1d.2-1
> input: Logitech USB Receiver as /class/input/input2
> input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.3-1
> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver

The difference is most likely meaningless; it is probably caused a
different order of initialization of the EHCI and UHCI controllers.

> Note that 3-1 is first assigned address 2 and then 4. With 2.6.26 3-1 did
> not have any problem accepting address 2. I assume the "unable to enumerate"
> error is a result of the rejection of the address?

No. It is caused by the EHCI controller being initialized.

When an EHCI controller is initialized, it switches all the USB
connections from its companion controllers to itself. Hence any device
which _was_ connected to the UHCI controller will _now_ be connected to
the EHCI controller. Consequently the UHCI controller is unable to
communicate with the device and cannot enumerate it.

After a short time, the EHCI controller driver realizes that the device
can't run at high speed and switches it back to the UHCI controller.
At that point it gets enumerated for the second time, successfully.

The difference must have been that under 2.6.26 the EHCI controller was
initialized _before_ the 3-1 device was detected, so there was no
aborted attempt at enumeration.

If you want to prevent all errors of this sort, all you have to do is
insure that ehci-hcd is loaded before either uhci-hcd or ohci-hcd
during system startup.

Alan Stern

2008-08-06 20:33:43

by Frans Pop

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Sunday 03 August 2008, Felipe Balbi wrote:
> On Sun, Aug 03, 2008 at 10:11:21PM +0200, Frans Pop wrote:
> > +usb 3-1: new low speed USB device using uhci_hcd and address 2
> > ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> > ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec
> > 2004 usb usb5: configuration #1 chosen from 1 choice
> > hub 5-0:1.0: USB hub found
> > -usb 3-1: new low speed USB device using uhci_hcd and address 2
> > +usb 3-1: device not accepting address 2, error -71
> > +hub 3-0:1.0: unable to enumerate USB device on port 1
>
> what is this device attached to this port ?

Eh, that info is already trivially available from my original mail:
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
[...]
input: USB Compliant Keyboard as /class/input/input0
input: USB HID v1.10 Keyboard [USB Compliant Keyboard] on usb-0000:00:1d.2-1
input: USB Compliant Keyboard as /class/input/input1
input: USB HID v1.10 Device [USB Compliant Keyboard] on usb-0000:00:1d.2-1

> Do you have the device attached before turning on the machine ?

Yes, obviously the keyboard is attached during boot (and has been connected
to the same USB port basically since I first installed the machine...).

> Does it happen if you boot without that device attached and attach
> it afterwards ?

No idea. I could try this I guess if it will really provide useful info.
Somehow I doubt that in this case.

> Can you please enable CONFIG_USB_DEBUG and resend dmesg output ?

Will include that in my reply to Alan's mail.

Cheers,
FJP

2008-08-06 20:54:32

by Felipe Balbi

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Wed, Aug 06, 2008 at 10:29:47PM +0200, Frans Pop wrote:
> Will include that in my reply to Alan's mail.

I think Alan's reply is already good enough. It's basically port
handover.

--
balbi

2008-08-06 21:28:48

by Frans Pop

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

Hi Alan,

On Monday 04 August 2008, Alan Stern wrote:
> > +usb 3-1: device not accepting address 2, error -71
> > +hub 3-0:1.0: unable to enumerate USB device on port 1
>
> The difference is most likely meaningless; it is probably caused a
> different order of initialization of the EHCI and UHCI controllers.

Meaningless, but annoying. Especially as such "errors" get through to the
console when you boot with the 'quiet' boot parameter and thus draw more
attention with "regular" users than they are really worth.

> > Note that 3-1 is first assigned address 2 and then 4. With 2.6.26 3-1
> > did not have any problem accepting address 2. I assume the "unable to
> > enumerate" error is a result of the rejection of the address?
>
> No. It is caused by the EHCI controller being initialized.
>
> When an EHCI controller is initialized, it switches all the USB
> connections from its companion controllers to itself. Hence any device
> which _was_ connected to the UHCI controller will _now_ be connected to
> the EHCI controller. Consequently the UHCI controller is unable to
> communicate with the device and cannot enumerate it.
>
> After a short time, the EHCI controller driver realizes that the device
> can't run at high speed and switches it back to the UHCI controller.
> At that point it gets enumerated for the second time, successfully.
>
> The difference must have been that under 2.6.26 the EHCI controller was
> initialized _before_ the 3-1 device was detected, so there was no
> aborted attempt at enumeration.

Thanks for the explanation. Attached boot messages (for -rc2) with usb
debug enabled as suggested by Felipe Balbi. Messages have been extracted
from kern.log (dmesg had already overflowed).

If I filter out messages related to bus 3 (PCI 1d.2) what I see is:
[...]
! usb 3-1: new low speed USB device using uhci_hcd and address 2
[ EHCI Host Controller gets initialized here for bus 5 ]
! usb 3-1: uhci_result_common: failed with status 440000
! usb 3-1: device not accepting address 2, error -71
! hub 3-0:1.0: unable to enumerate USB device on port 1
! hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
! hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
! uhci_hcd 0000:00:1d.2: port 1 portsc 01a3,00
! hub 3-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
! hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
! usb 3-1: new low speed USB device using uhci_hcd and address 4
[...]

I guess that does match your description.

I do find it a bit strange though that EHCI is allowed to grab bus 3 when
UHCI has already identified a low speed device on that bus.

> If you want to prevent all errors of this sort, all you have to do is
> insure that ehci-hcd is loaded before either uhci-hcd or ohci-hcd
> during system startup.

Hmmm. Also not sure that I'm ready to agree with this conclusion.

Shouldn't the kernel itself be smart enough to prevent error messages in
apparently predictable and probably fairly common scenarios?

To me this seems a lot like an issue discussed during the .25 cycle in
http://lkml.org/lkml/2008/5/2/256
which was eventually fixed by you with
3a31155c Alan Stern, "USB: EHCI: suppress unwanted error messages"

Cheers,
FJP


Attachments:
(No filename) (3.14 kB)
usb-debug_2.6.27-rc2 (80.96 kB)
Download all attachments

2008-08-06 22:28:13

by Alan Stern

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Wed, 6 Aug 2008, Frans Pop wrote:

> I do find it a bit strange though that EHCI is allowed to grab bus 3 when
> UHCI has already identified a low speed device on that bus.

Here's how it works. An EHCI controller contains a bank of switches,
one for each port. By default, the switches are set so that each port
connects to the companion UHCI (or OHCI) controller; that way you get
USB-1.1 functionality even if ehci-hcd isn't loaded.

But when the driver loads, it resets the switches so that the ports
connect to the EHCI controller. There is no way for the driver to tell
which ports have devices attached and which don't, so it has to reset
all the switches. Thus, any device which was connected to the UHCI
controller is now connected to the EHCI controller. As far as uhci-hcd
is concerned, it appears that all the devices were suddenly plugged.

As each device is enumerated, ehci-hcd determines whether it can run at
high speed. If not, the corresponding switch is set so the device
connects back to the UHCI controller and it runs at full/low speed.

> > If you want to prevent all errors of this sort, all you have to do is
> > insure that ehci-hcd is loaded before either uhci-hcd or ohci-hcd
> > during system startup.
>
> Hmmm. Also not sure that I'm ready to agree with this conclusion.

It follows directly from the description above. If ehci-hcd is loaded
first then all the switches will be reset before any device has a
chance to register the UHCI driver. Hence uhci-hcd will never see them
suddenly disconnect and will not generate those error messages.

> Shouldn't the kernel itself be smart enough to prevent error messages in
> apparently predictable and probably fairly common scenarios?

It's somewhat difficult to synchronize activities between two different
drivers, especially when they can be in separate modules (so that one
might be present in memory and the other not).

As for whether these messages really _should_ be suppressed... That
depends on the circumstances. In your case, yes. But suppose for some
reason ehci-hcd was loaded much later, at a time when the devices
connected to the UHCI controller were already in use. In that case it
seems reasonable to log some error messages when the devices stop
working.

> To me this seems a lot like an issue discussed during the .25 cycle in
> http://lkml.org/lkml/2008/5/2/256
> which was eventually fixed by you with
> 3a31155c Alan Stern, "USB: EHCI: suppress unwanted error messages"

That didn't involve cooperation between ehci-hcd and uhci-hcd.

Alan Stern

2008-08-09 13:48:18

by Diego Zuccato

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

Alan Stern ha scritto:

> As each device is enumerated, ehci-hcd determines whether it can run at
> high speed. If not, the corresponding switch is set so the device
> connects back to the UHCI controller and it runs at full/low speed.
Urgh... What happens if it contains a mounted filesystem?
Seems quite dangerous...

BYtE,
Diego.

2008-08-09 15:26:53

by Felipe Balbi

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Sat, Aug 09, 2008 at 03:27:34PM +0200, Diego Zuccato wrote:
> Urgh... What happens if it contains a mounted filesystem?
> Seems quite dangerous...

It still enumerating, you'll never have a mounted fs at this point :-)

--
balbi

2008-08-10 15:46:25

by Alan Stern

[permalink] [raw]
Subject: Re: [regression?] usb: new errors during device detection

On Sat, 9 Aug 2008, Diego Zuccato wrote:

> Alan Stern ha scritto:
>
> > As each device is enumerated, ehci-hcd determines whether it can run at
> > high speed. If not, the corresponding switch is set so the device
> > connects back to the UHCI controller and it runs at full/low speed.
> Urgh... What happens if it contains a mounted filesystem?
> Seems quite dangerous...

It's no more dangerous than somebody unplugging the USB cable by
mistake. :-)

Alan Stern

2008-08-26 19:04:35

by Frans Pop

[permalink] [raw]
Subject: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

Sorry for the delay since the last message, but I needed to digest this a
bit and also did not see any point in degenerating the (so far very
useful) discussion into a yes-no-yes-no flamefest.

Below some comments and an extra what looks to be real regression.

On Thursday 07 August 2008, Alan Stern wrote:
> On Wed, 6 Aug 2008, Frans Pop wrote:
> > I do find it a bit strange though that EHCI is allowed to grab bus 3
> > when UHCI has already identified a low speed device on that bus.
>
> Here's how it works. An EHCI controller contains a bank of switches,
> one for each port. By default, the switches are set so that each port
> connects to the companion UHCI (or OHCI) controller; that way you get
> USB-1.1 functionality even if ehci-hcd isn't loaded.
>
> But when the driver loads, it resets the switches so that the ports
> connect to the EHCI controller. There is no way for the driver to tell
> which ports have devices attached and which don't, so it has to reset
> all the switches. Thus, any device which was connected to the UHCI
> controller is now connected to the EHCI controller. As far as uhci-hcd
> is concerned, it appears that all the devices were suddenly plugged.
>
> As each device is enumerated, ehci-hcd determines whether it can run at
> high speed. If not, the corresponding switch is set so the device
> connects back to the UHCI controller and it runs at full/low speed.

Thanks a lot for the explanation Alan. I get the general idea and it all
sounds somewhat logical if you accept the fact that EHCI can be loaded at
any random time after [UO]HCI as a given, but _that_ still seems to me
(admittedly a relative outsider and not hindered by any actual technical
knowledge ;-) like something that is fundamentally broken in this
sequence.

It also seems to be fragile in practice. I have now had two occasions
since your last mail where my system would come up with a dead USB
keyboard and it looks like this issue is the root cause.

Attached a full diff between dmesg from two consecutive boots: first
without keyboard; after reboot the keyboard is detected. The actual
difference is fairly small and clearly shows that usb 3-1 is not handed
off correctly, probably due to a small difference in timing.

Note that I've never seen this problem with earlier kernels.

> > > If you want to prevent all errors of this sort, all you have to do
> > > is insure that ehci-hcd is loaded before either uhci-hcd or
> > > ohci-hcd during system startup.
> >
> > Hmmm. Also not sure that I'm ready to agree with this conclusion.
>
> It follows directly from the description above. If ehci-hcd is loaded
> first then all the switches will be reset before any device has a
> chance to register the UHCI driver. Hence uhci-hcd will never see them
> suddenly disconnect and will not generate those error messages.

I still feel it should not be up to individual users to need to "force"
something like this by manually messing with their initramfs or
/etc/modules. If loading EHCI first is the right thing to do (and it seems
to me like it is) then the kernel itself should ensure that that's what
happens.

> > Shouldn't the kernel itself be smart enough to prevent error messages
> > in apparently predictable and probably fairly common scenarios?
>
> It's somewhat difficult to synchronize activities between two different
> drivers, especially when they can be in separate modules (so that one
> might be present in memory and the other not).

Ack.

> As for whether these messages really _should_ be suppressed... That
> depends on the circumstances. In your case, yes. But suppose for some
> reason ehci-hcd was loaded much later, at a time when the devices
> connected to the UHCI controller were already in use. In that case it
> seems reasonable to log some error messages when the devices stop
> working.

From an end-user PoV (which basically I am) I personally actually don't
think it is reasonable to have _any_ error messages in situations that
are expected and part of a "normal" boot sequence. For me, error messages
always indicate that something is wrong or broken and needs to be fixed
and followed up on. So, if this driver hand-off is really necessary,
expected and safe, it should be done with only informational messages,
not errors.

Even in the case where ehci-hcd is loaded much later I don't think error
messages would be right. At least, assuming that the kernel can guarantee
that the driver hand-off can be done cleanly (without risk of damaging
interruptions in the working of already connected devices). And if it
cannot guarantee that, then maybe it should just refuse to load ehci-hcd
at all!


Side note.
Both as a Debian Developer and kernel tester I probably pay more attention
than most users to my console and logs, but in principle I try to follow
up on any message that does not seem to belong, especially ones that
are "new".
I boot kernels with 'quiet', so any error during boot is immediately
visible (and disturbing). I also run logcheck on all my systems, so I see
any unexpected log messages during normal operation. As boot logs are
noisy by definition, I finally do diffs between old and new boot time
dmesg after most new (rc) kernel builds.

Call it my contribution to quality assurance.

Cheers,
FJP


Attachments:
(No filename) (5.19 kB)
dmesg.no_keyboard.diff (35.75 kB)
Download all attachments

2008-08-26 20:53:45

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

On Tue, 26 Aug 2008, Frans Pop wrote:

> Thanks a lot for the explanation Alan. I get the general idea and it all
> sounds somewhat logical if you accept the fact that EHCI can be loaded at
> any random time after [UO]HCI as a given, but _that_ still seems to me
> (admittedly a relative outsider and not hindered by any actual technical
> knowledge ;-) like something that is fundamentally broken in this
> sequence.

The arrangement certainly isn't perfect. Partly it's an historical
artifact, arising from the way USB 2.0 controller hardware was
"designed" to work with existing USB 1.1 devices. (I put "designed" in
quotes because that's just what they didn't do -- they came up with a
separate chip to handle the high-speed connections and left the
full/low-speed connections to be handled by the old hardware.)

> It also seems to be fragile in practice. I have now had two occasions
> since your last mail where my system would come up with a dead USB
> keyboard and it looks like this issue is the root cause.

It isn't any more fragile than unplugging the USB cable and then
plugging it back in. If your system can't handle that sort of thing
then something else is wrong. I.e., you've run across a bug, not a
design flaw.

> Attached a full diff between dmesg from two consecutive boots: first
> without keyboard; after reboot the keyboard is detected. The actual
> difference is fairly small and clearly shows that usb 3-1 is not handed
> off correctly, probably due to a small difference in timing.
>
> Note that I've never seen this problem with earlier kernels.

I can't tell exactly what's going on because your usbcore module wasn't
built with CONFIG_USB_DEBUG enabled.

Have you experimented with unloading and reloading uhci-hcd and
ehci-hcd by hand (over the network if your only keyboard is USB)? If
you remove both and then load uhci-hcd first followed by ehci-hcd, does
the same thing happen?

> I still feel it should not be up to individual users to need to "force"
> something like this by manually messing with their initramfs or
> /etc/modules. If loading EHCI first is the right thing to do (and it seems
> to me like it is) then the kernel itself should ensure that that's what
> happens.

The kernel has very little control over the order in which modules are
loaded, partly because loading is carried out by programs like udev
running in userspace and partly because there can be multiple threads
sending out device-discovery messages in parallel.

With UHCI and EHCI things are made even worse by the fact that UHCI is
always discovered first. The EHCI spec requires that the companion
controllers have the lowest PCI function numbers and the EHCI
controller has the highest. You can see this in your log, where 1d.0
through 1d.3 are UHCI devices and 1d.7 is EHCI. Since PCI devices are
probed in order of function number, the natural result is that uhci-hcd
will be loaded before ehci-hcd.

> From an end-user PoV (which basically I am) I personally actually don't
> think it is reasonable to have _any_ error messages in situations that
> are expected and part of a "normal" boot sequence. For me, error messages
> always indicate that something is wrong or broken and needs to be fixed
> and followed up on. So, if this driver hand-off is really necessary,
> expected and safe, it should be done with only informational messages,
> not errors.
>
> Even in the case where ehci-hcd is loaded much later I don't think error
> messages would be right. At least, assuming that the kernel can guarantee
> that the driver hand-off can be done cleanly (without risk of damaging
> interruptions in the working of already connected devices). And if it
> cannot guarantee that, then maybe it should just refuse to load ehci-hcd
> at all!

Well, that's a problem. The kernel _can't_ make that guarantee, not
once some USB devices have been set up. So according to your
reasoning, ehci-hcd shouldn't be allowed to load if uhci-hcd is already
loaded!

Can you suggest a reasonable method for suppressing the unwanted error
messages? Maybe I'm too close to the problem, but nothing occurs to
me. Part of the problem is that these errors could occur at any point
during the life cycle of a USB device: during detection, during
enumeration, during configuration, or during normal operation. It
doesn't seem reasonable to have a flag to suppress _every_ error
message generated by the USB subsystem.

One possible approach would be to have uhci-hcd and ohci-hcd not
initialize themselves until ehci-hcd is loaded. But what if ehci-hcd
never does get loaded? Or what if ehci-hcd is unloaded and then
reloaded?

> Side note.
> Both as a Debian Developer and kernel tester I probably pay more attention
> than most users to my console and logs, but in principle I try to follow
> up on any message that does not seem to belong, especially ones that
> are "new".
> I boot kernels with 'quiet', so any error during boot is immediately
> visible (and disturbing). I also run logcheck on all my systems, so I see
> any unexpected log messages during normal operation. As boot logs are
> noisy by definition, I finally do diffs between old and new boot time
> dmesg after most new (rc) kernel builds.
>
> Call it my contribution to quality assurance.

Kernel developers appreciate such keen oversight. Thank you.

Alan Stern

2008-08-29 13:04:17

by Frans Pop

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

On Tuesday 26 August 2008, Alan Stern wrote:
> > It also seems to be fragile in practice. I have now had two occasions
> > since your last mail where my system would come up with a dead USB
> > keyboard and it looks like this issue is the root cause.
>
> It isn't any more fragile than unplugging the USB cable and then
> plugging it back in. If your system can't handle that sort of thing
> then something else is wrong. I.e., you've run across a bug, not a
> design flaw.

The fragile part IMO is that the kernel currently allows the loading of
ehci to interrupt the initialization of uhci/ohci and *that* is what is
causing the errors.

I have run some tests loading ehci and uhci manually and when they are
done separately (i.e. with a little delay between the two) there are no
errors at all!

If uhci is loaded first, you only get a nice, clean "USB disconnect"
message (for devices already detected by uhci) when ehci is loaded.
If ehci is loaded first the low-speed devices are only detected after uhci
is loaded as well.

The *only* time you get the "device not accepting address" and "unable to
enumerate" errors is when you allow the ehci initialization to interrupt
the uhci initialization. IMO that cannot be classified anything other
than a bug.

See also the attachments with dmesg output:
- modprobe_uhci-ehci: uhci first; ehci later
- modprobe_ehci-uhci: ehci first; uhci later
- modprobe_uhci+ehci: both simultaneously (uhci slightly earlier)

> > Attached a full diff between dmesg from two consecutive boots: first
> > without keyboard; after reboot the keyboard is detected. The actual
> > difference is fairly small and clearly shows that usb 3-1 is not
> > handed off correctly, probably due to a small difference in timing.
> >
> > Note that I've never seen this problem with earlier kernels.
>
> I can't tell exactly what's going on because your usbcore module wasn't
> built with CONFIG_USB_DEBUG enabled.

Two problems:
- CONFIG_USB_DEBUG causes such a huge load of output that it is totally
unacceptable to have that enabled permanently for a running system
- I cannot reproduce this issue on demand, even though I've tried with
various delays between loading uhci and ehci

Possibly with the new patches from Greg KH [1] it would be possible to
disable USB debugging automatically when system boot is completed, but
I'd have to build a kernel with those and wait for the problem to happen
again.

What I can see in the logs I do have is that in the error case for some
reason a "reset low speed USB device" is triggered instead of either an
"enumeration failure" or a "USB disconnect", which are what I normally
see. As mentioned before, this seems to indicate to me a subtle timing
difference between the boots and IMO confirms the danger of allowing the
initialization of ehci to interrupt an ongoing initialization of uhci.

My guess is that this "reset" is insufficient to cause the bus to be
properly rescanned when ehci hands it back to uhci. I also guess that a
"reset" can occur if the interruption by the ehci loading happens
somewhere between the times that would otherwise cause an "enumeration
failure" and a clean "USB disconnect".

> Have you experimented with unloading and reloading uhci-hcd and
> ehci-hcd by hand (over the network if your only keyboard is USB)?

I have now. See results and comments above.

> If you remove both and then load uhci-hcd first followed by ehci-hcd,
> does the same thing happen?

No, unfortunately I cannot reproduce it on demand. Probably because the
timing is too subtle and the "window" in which the problem occurs is
quite small.

> > Even in the case where ehci-hcd is loaded much later I don't think
> > error messages would be right. At least, assuming that the kernel can
> > guarantee that the driver hand-off can be done cleanly (without risk
> > of damaging interruptions in the working of already connected
> > devices). And if it cannot guarantee that, then maybe it should just
> > refuse to load ehci-hcd at all!
>
> Well, that's a problem. The kernel _can't_ make that guarantee, not
> once some USB devices have been set up. So according to your
> reasoning, ehci-hcd shouldn't be allowed to load if uhci-hcd is already
> loaded!

You made the comment that this issue isn't worse than yanking out
cables/devices at random times. AFAIK it is still very much discouraged
to do that for e.g. storage devices, especially when data has recently
been written to them, without at least syncing and preferably unmounting
the device first. For a lot of devices (like keyboards) it doesn't really
matter of course.
There is one huge difference though: if a user yanks out a (storage)
device while it is in use he's just being dumb and IMO deserves what he
gets. It's basically the same as pulling a SATA cable or the power cable
of a desktop system.
But when the _kernel_ does the same, it is IMO being irresponsible.

I'm don't think it is reasonable to go so far as to completely prohibit
ehci from loading after uhci, especially not during system boot. But
maybe it should be made to first check with the low speed drivers what
their state is _before_ just barging in and rudely interrupting things on
the hardware level.

And maybe the kernel should (eventually) even go so far as to check
whether a low speed USB driver is in use by a mounted storage device and
maybe then loading ehci should be blocked. Just as 'modprobe -r' for a
ATA module is blocked if the driver is still in use.

> Can you suggest a reasonable method for suppressing the unwanted error
> messages? Maybe I'm too close to the problem, but nothing occurs to
> me. Part of the problem is that these errors could occur at any point
> during the life cycle of a USB device: during detection, during
> enumeration, during configuration, or during normal operation. It
> doesn't seem reasonable to have a flag to suppress _every_ error
> message generated by the USB subsystem.

My tests show that it is quite easy to avoid errors by just making sure
that ehci does not interrupt *the initialization process* of uhci.
Wouldn't it be possible to let ehci first check the state of the
uhci/ohci drivers and to have it *delay* its own initialization if those
are still busy initializing themselves?
Conversely uhci/ohci should probably not respond to new devices being
plugged in when they have been notified by ehci that it wants to (or has
started to) initialize itself.

Another option (probably on top of the above suggestion) would be to
slightly delay ohci/uhci initialization during system boot. This would
allow the general hardware discovery process to reach the later ehci PCI
device and start the ehci initialization.
ohci/uhci initialization could then start after ehci initialization has
completed; if no ehci device is present, ohci/uhci initialization would
still just start after the delay times out.
My boot logs show that the devices are generally detected within the same
second, so such a delay could be quite short.


Does this sound at all logical and feasible?

Cheers,
FJP

[1] http://lkml.org/lkml/2008/8/8/529


Attachments:
(No filename) (6.98 kB)
modprobe_ehci-uhci (2.69 kB)
modprobe_uhci-ehci (3.35 kB)
modprobe_uhci+ehci (2.85 kB)
Download all attachments

2008-08-29 17:06:16

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

On Fri, 29 Aug 2008, Frans Pop wrote:

> On Tuesday 26 August 2008, Alan Stern wrote:
> > > It also seems to be fragile in practice. I have now had two occasions
> > > since your last mail where my system would come up with a dead USB
> > > keyboard and it looks like this issue is the root cause.
> >
> > It isn't any more fragile than unplugging the USB cable and then
> > plugging it back in. If your system can't handle that sort of thing
> > then something else is wrong. I.e., you've run across a bug, not a
> > design flaw.
>
> The fragile part IMO is that the kernel currently allows the loading of
> ehci to interrupt the initialization of uhci/ohci and *that* is what is
> causing the errors.

It doesn't interrupt just the initialization of UHCI/OHCI -- it
interrupts all their activities.

And I wouldn't say the kernel "allows" this to happen. More like it
has no choice.

> I have run some tests loading ehci and uhci manually and when they are
> done separately (i.e. with a little delay between the two) there are no
> errors at all!

You have to be careful when making statements like that. All you know
is that no error messages showed up _in the log_. But I'll bet there
were plenty of errors.

In your attached logs you tested with a keyboard and wireless mouse
receiver. The USB HID driver is careful not to send error messages to
the log as soon as it encounters I/O errors; instead it retries at
various increasing intervals for a while before giving up. Long enough
for the disconnect notification to be received.

If you would use usbmon (see Documentation/usb/usbmon.txt) to record
what those HID drivers actually send and receive when ehci-hcd is
loaded, you will see that errors did indeed occur.

> If uhci is loaded first, you only get a nice, clean "USB disconnect"
> message (for devices already detected by uhci) when ehci is loaded.

More accurately, you get exactly the same sequence of events as if you
had unplugged the USB cable. Sometimes it's a nice clean disconnect
message, and sometimes that message is preceded by a string of error
messages. It depends on how the device is being used at the time.

Do you have a USB flash drive? Try plugging that in and running
something like "cat /dev/sdX >/dev/null" when you load ehci-hcd.

> If ehci is loaded first the low-speed devices are only detected after uhci
> is loaded as well.

As they should be.

> The *only* time you get the "device not accepting address" and "unable to
> enumerate" errors is when you allow the ehci initialization to interrupt
> the uhci initialization. IMO that cannot be classified anything other
> than a bug.

That's hardly a surprise -- those messages are emitted by the device
initialization code. So what you're saying is circular: The only time
you get initialization errors is when you interrupt device
initialization. Well of course!

> > I can't tell exactly what's going on because your usbcore module wasn't
> > built with CONFIG_USB_DEBUG enabled.
>
> Two problems:
> - CONFIG_USB_DEBUG causes such a huge load of output that it is totally
> unacceptable to have that enabled permanently for a running system

It shouldn't do that. Almost all of the extra output occurs when
devices are plugged in or unplugged; during normal operation there
should be very few extra messages. (Depending on what USB drivers you
use, I suppose...)

> - I cannot reproduce this issue on demand, even though I've tried with
> various delays between loading uhci and ehci

That's unforunate.

> Possibly with the new patches from Greg KH [1] it would be possible to
> disable USB debugging automatically when system boot is completed, but
> I'd have to build a kernel with those and wait for the problem to happen
> again.
>
> What I can see in the logs I do have is that in the error case for some
> reason a "reset low speed USB device" is triggered instead of either an
> "enumeration failure" or a "USB disconnect", which are what I normally
> see.

There should always be a USB disconnect, unless the interruption
occurs before the low-speed device was registered in the first place.

> As mentioned before, this seems to indicate to me a subtle timing
> difference between the boots and IMO confirms the danger of allowing the
> initialization of ehci to interrupt an ongoing initialization of uhci.
>
> My guess is that this "reset" is insufficient to cause the bus to be
> properly rescanned when ehci hands it back to uhci. I also guess that a
> "reset" can occur if the interruption by the ehci loading happens
> somewhere between the times that would otherwise cause an "enumeration
> failure" and a clean "USB disconnect".

Offhand I can't think what time that would be. Which is why having a
debugging log would be a big help. Unlike those error messages you
dislike so much, this sounds like a genuine bug.

> You made the comment that this issue isn't worse than yanking out
> cables/devices at random times. AFAIK it is still very much discouraged
> to do that for e.g. storage devices, especially when data has recently
> been written to them, without at least syncing and preferably unmounting
> the device first. For a lot of devices (like keyboards) it doesn't really
> matter of course.

True.

> There is one huge difference though: if a user yanks out a (storage)
> device while it is in use he's just being dumb and IMO deserves what he
> gets.

Or clumsy (tripped over the cable). :-)

> It's basically the same as pulling a SATA cable or the power cable
> of a desktop system.
> But when the _kernel_ does the same, it is IMO being irresponsible.
>
> I'm don't think it is reasonable to go so far as to completely prohibit
> ehci from loading after uhci, especially not during system boot. But
> maybe it should be made to first check with the low speed drivers what
> their state is _before_ just barging in and rudely interrupting things on
> the hardware level.

What exactly should it check for?

> And maybe the kernel should (eventually) even go so far as to check
> whether a low speed USB driver is in use by a mounted storage device and
> maybe then loading ehci should be blocked. Just as 'modprobe -r' for a
> ATA module is blocked if the driver is still in use.

Linus made a similar suggestion (regarding a different problem) some
time within the last year. After looking into the matter he realized
that it is very difficult, effectively impossible, to tell at the USB
level whether a storage device is mounted.

Besides, what happens during your boot-up procedure if ehci-hcd is too
slow? A storage device will be discovered and mounted using uhci-hcd,
and then ehci-hcd would _never_ get loaded!

> My tests show that it is quite easy to avoid errors by just making sure
> that ehci does not interrupt *the initialization process* of uhci.

I think that's an oversimplification, but never mind. (And actually
you don't mean the initialization process of uhci-hcd; you mean that a
device attached to a UHCI controller is being initialized.)

> Wouldn't it be possible to let ehci first check the state of the
> uhci/ohci drivers and to have it *delay* its own initialization if those
> are still busy initializing themselves?

It would be possible to have ehci-hcd delay initializing its controller
while other USB devices are being initialized. Or more generally,
while khubd was running.

It's not at all clear (to me at least) whether this would solve any
_real_ problems. It might do nothing more than prevent certain sorts
of error messages from appearing in the system log. But I guess that
would be good enough for you...

> Conversely uhci/ohci should probably not respond to new devices being
> plugged in when they have been notified by ehci that it wants to (or has
> started to) initialize itself.

By then it's too late; devices that were attached previously will
already be in the middle of their initialization procedures.

> Another option (probably on top of the above suggestion) would be to
> slightly delay ohci/uhci initialization during system boot. This would
> allow the general hardware discovery process to reach the later ehci PCI
> device and start the ehci initialization.

People would _really_ dislike that! They do not want to endure extra
delays before they can start typing on their USB keyboards.

> ohci/uhci initialization could then start after ehci initialization has
> completed; if no ehci device is present, ohci/uhci initialization would
> still just start after the delay times out.

That won't work in situations where uhci-hcd and ehci-hcd are built
into the kernel, as opposed to being loadable modules.

> My boot logs show that the devices are generally detected within the same
> second, so such a delay could be quite short.

Ha! Someone on LKML (I forget who) mentioned just a few weeks ago that
his system could boot up to the user prompt in only 2 seconds, and he
certainly wouldn't put up with an extra one-second delay merely to
avoid a few error message in the log.

> Does this sound at all logical and feasible?

The first proposal is feasible; I can write a patch to implement it.
How much it will end up helping anything isn't clear, though.

Alan Stern

2008-08-29 17:33:57

by Frans Pop

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

Just replying to one comment now, the rest will need more thought :-)

On Friday 29 August 2008, Alan Stern wrote:
> > Two problems:
> > - CONFIG_USB_DEBUG causes such a huge load of output that it is
> > totally unacceptable to have that enabled permanently for a running
> > system
>
> It shouldn't do that. Almost all of the extra output occurs when
> devices are plugged in or unplugged; during normal operation there
> should be very few extra messages. (Depending on what USB drivers you
> use, I suppose...)

Here's a snippet of what I got when I enabled USB debug recently:
[...]
Aug 6 22:06:23 faramir kernel: hub 2-0:1.0: hub_resume
Aug 6 22:06:23 faramir kernel: hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
Aug 6 22:06:23 faramir kernel: usb usb1: usb auto-resume
Aug 6 22:06:23 faramir kernel: usb usb1: wakeup_rh
Aug 6 22:06:23 faramir kernel: hub 1-0:1.0: hub_resume
Aug 6 22:06:23 faramir kernel: hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
Aug 6 22:06:24 faramir kernel: usb usb2: suspend_rh (auto-stop)
Aug 6 22:06:24 faramir kernel: usb usb1: suspend_rh (auto-stop)
Aug 6 22:06:25 faramir kernel: hub 5-0:1.0: hub_suspend
Aug 6 22:06:25 faramir kernel: usb usb5: bus auto-suspend
Aug 6 22:06:25 faramir kernel: ehci_hcd 0000:00:1d.7: suspend root hub
Aug 6 22:06:25 faramir kernel: hub 2-0:1.0: hub_suspend
Aug 6 22:06:25 faramir kernel: usb usb2: bus auto-suspend
Aug 6 22:06:25 faramir kernel: usb usb2: suspend_rh
Aug 6 22:06:25 faramir kernel: hub 1-0:1.0: hub_suspend
Aug 6 22:06:25 faramir kernel: usb usb1: bus auto-suspend
Aug 6 22:06:25 faramir kernel: usb usb1: suspend_rh
Aug 6 22:06:28 faramir kernel: usb usb5: usb auto-resume
Aug 6 22:06:28 faramir kernel: ehci_hcd 0000:00:1d.7: resume root hub
Aug 6 22:06:28 faramir kernel: hub 5-0:1.0: hub_resume
Aug 6 22:06:28 faramir kernel: hub 5-0:1.0: state 7 ports 8 chg 0000 evt fe00
Aug 6 22:06:28 faramir kernel: usb usb2: usb auto-resume
Aug 6 22:06:28 faramir kernel: usb usb2: wakeup_rh
Aug 6 22:06:28 faramir kernel: hub 2-0:1.0: hub_resume
Aug 6 22:06:28 faramir kernel: usb usb1: usb auto-resume
Aug 6 22:06:28 faramir kernel: usb usb1: wakeup_rh
Aug 6 22:06:28 faramir kernel: hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
Aug 6 22:06:28 faramir kernel: hub 1-0:1.0: hub_resume
Aug 6 22:06:28 faramir kernel: hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
Aug 6 22:06:29 faramir kernel: usb usb2: suspend_rh (auto-stop)
Aug 6 22:06:29 faramir kernel: usb usb1: suspend_rh (auto-stop)
[...]

AFAIK I have not enabled anything special in userland when it comes to
USB suspension; this is just a standard boot.
I do have CONFIG_USB_SUSPEND enabled though, so maybe one should not do that
when using USB_DEBUG?

2008-08-29 21:22:28

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

On Fri, 29 Aug 2008, Frans Pop wrote:

> Here's a snippet of what I got when I enabled USB debug recently:
> [...]
> Aug 6 22:06:23 faramir kernel: hub 2-0:1.0: hub_resume
> Aug 6 22:06:23 faramir kernel: hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
> Aug 6 22:06:23 faramir kernel: usb usb1: usb auto-resume
> Aug 6 22:06:23 faramir kernel: usb usb1: wakeup_rh
> Aug 6 22:06:23 faramir kernel: hub 1-0:1.0: hub_resume
> Aug 6 22:06:23 faramir kernel: hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
> Aug 6 22:06:24 faramir kernel: usb usb2: suspend_rh (auto-stop)
> Aug 6 22:06:24 faramir kernel: usb usb1: suspend_rh (auto-stop)
> Aug 6 22:06:25 faramir kernel: hub 5-0:1.0: hub_suspend
> Aug 6 22:06:25 faramir kernel: usb usb5: bus auto-suspend
> Aug 6 22:06:25 faramir kernel: ehci_hcd 0000:00:1d.7: suspend root hub
> Aug 6 22:06:25 faramir kernel: hub 2-0:1.0: hub_suspend
> Aug 6 22:06:25 faramir kernel: usb usb2: bus auto-suspend
> Aug 6 22:06:25 faramir kernel: usb usb2: suspend_rh
> Aug 6 22:06:25 faramir kernel: hub 1-0:1.0: hub_suspend
> Aug 6 22:06:25 faramir kernel: usb usb1: bus auto-suspend
> Aug 6 22:06:25 faramir kernel: usb usb1: suspend_rh
> Aug 6 22:06:28 faramir kernel: usb usb5: usb auto-resume
> Aug 6 22:06:28 faramir kernel: ehci_hcd 0000:00:1d.7: resume root hub
> Aug 6 22:06:28 faramir kernel: hub 5-0:1.0: hub_resume
> Aug 6 22:06:28 faramir kernel: hub 5-0:1.0: state 7 ports 8 chg 0000 evt fe00
> Aug 6 22:06:28 faramir kernel: usb usb2: usb auto-resume
> Aug 6 22:06:28 faramir kernel: usb usb2: wakeup_rh
> Aug 6 22:06:28 faramir kernel: hub 2-0:1.0: hub_resume
> Aug 6 22:06:28 faramir kernel: usb usb1: usb auto-resume
> Aug 6 22:06:28 faramir kernel: usb usb1: wakeup_rh
> Aug 6 22:06:28 faramir kernel: hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
> Aug 6 22:06:28 faramir kernel: hub 1-0:1.0: hub_resume
> Aug 6 22:06:28 faramir kernel: hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
> Aug 6 22:06:29 faramir kernel: usb usb2: suspend_rh (auto-stop)
> Aug 6 22:06:29 faramir kernel: usb usb1: suspend_rh (auto-stop)
> [...]
>
> AFAIK I have not enabled anything special in userland when it comes to
> USB suspension; this is just a standard boot.

Maybe you haven't enabled anything special, but something sure is
running. It appears to be probing your USB devices every 5 seconds.
You might be able to find out what it is by adding

printk(KERN_INFO "usbdev open by %s\n", current->comm);

to usbdev_open() in drivers/usb/core/devio.c.

> I do have CONFIG_USB_SUSPEND enabled though, so maybe one should not do that
> when using USB_DEBUG?

Turning off CONFIG_USB_SUSPEND would get rid of most but not all of
those messages above.

Alan Stern

2008-08-30 02:48:58

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (was: new errors during device detection)

On Fri, 29 Aug 2008, Alan Stern wrote:

> > Does this sound at all logical and feasible?
>
> The first proposal is feasible; I can write a patch to implement it.
> How much it will end up helping anything isn't clear, though.

Here's the promised patch. Be warned, I haven't tested it at all.

Alan Stern


Index: usb-2.6/drivers/usb/core/hcd.h
===================================================================
--- usb-2.6.orig/drivers/usb/core/hcd.h
+++ usb-2.6/drivers/usb/core/hcd.h
@@ -486,4 +486,7 @@ static inline void usbmon_urb_complete(s
*/
extern struct rw_semaphore ehci_cf_port_reset_rwsem;

+/* This is also for use by khubd and ehci-hcd. */
+extern void usb_wait_for_khubd_idle(void);
+
#endif /* __KERNEL__ */
Index: usb-2.6/drivers/usb/core/hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -3097,6 +3097,16 @@ loop:
} /* end while (1) */
}

+/* Let ehci-hcd know when khubd is idle */
+static int khubd_active;
+static DECLARE_WAIT_QUEUE_HEAD(khubd_wqh);
+
+void usb_wait_for_khubd_idle(void)
+{
+ wait_event(khubd_wqh, !khubd_active);
+}
+EXPORT_SYMBOL_GPL(usb_wait_for_khubd_idle);
+
static int hub_thread(void *__unused)
{
/* khubd needs to be freezable to avoid intefering with USB-PERSIST
@@ -3107,7 +3117,11 @@ static int hub_thread(void *__unused)
set_freezable();

do {
+ khubd_active = 1;
hub_events();
+ khubd_active = 0;
+ wake_up_all(&khubd_wqh);
+
wait_event_freezable(khubd_wait,
!list_empty(&hub_event_list) ||
kthread_should_stop());
Index: usb-2.6/drivers/usb/host/ehci-hcd.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-hcd.c
+++ usb-2.6/drivers/usb/host/ehci-hcd.c
@@ -604,7 +604,13 @@ static int ehci_run (struct usb_hcd *hcd
* guarantees that no resets are in progress. After we set CF,
* a short delay lets the hardware catch up; new resets shouldn't
* be started before the port switching actions could complete.
+ *
+ * In an attempt to avoid unwanted initialization error messages
+ * for devices attached to companion controllers, we will wait
+ * until khubd is idle before beginning. This isn't truly a
+ * general solution but it should help during system bootup.
*/
+ usb_wait_for_khubd_idle();
down_write(&ehci_cf_port_reset_rwsem);
hcd->state = HC_STATE_RUNNING;
ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);

2008-08-30 10:44:33

by Frans Pop

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot

On Friday 29 August 2008, you wrote:
> Maybe you haven't enabled anything special, but something sure is
> running. It appears to be probing your USB devices every 5 seconds.
> You might be able to find out what it is by adding
>
> printk(KERN_INFO "usbdev open by %s\n", current->comm);
>
> to usbdev_open() in drivers/usb/core/devio.c.

Thanks a lot. That identified the culprit: brltty (which I only have
installed for some very rare testing with the Debian Installer).

I'll file a bug in the Debian BTS as I know the Debian maintainer has very
good contacts with the upstream developers.

2008-08-30 14:40:44

by Frans Pop

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot

On Saturday 30 August 2008, Alan Stern wrote:
> On Fri, 29 Aug 2008, Alan Stern wrote:
> > > Does this sound at all logical and feasible?
> >
> > The first proposal is feasible; I can write a patch to implement it.
> > How much it will end up helping anything isn't clear, though.
>
> Here's the promised patch. Be warned, I haven't tested it at all.

The patch seems to do exactly what I was looking for! Details further
down, but first some other comments.


My first boot with your patch was with brltty still enabled. The log
showed the right result, but I wanted to get a cleaner log without all
the USB suspend/resume noise caused by brltty. So I disabled brltty's
init script and rebooted.

This gave a totally unexpected result: ehci now got loaded and initialized
_before_ uhci which of course avoids the problem altogether (see attached
log: dmesg_ehci-first). So apparently brltty's init script was
responsible not only for the suspend/resume noise, but also influenced
the load order of the two USB drivers.
And apparently when things are left alone ehci _will_ be loaded before
uhci, but that does not match what you described in earlier mails as it
means the PCI bus order isn't followed. Confusing...


Anyway, this meant that to test your patch I had to try to get uhci to
load first again. This turned out to be simple: just adding uhci_hcd
in /etc/modules did the trick. The result is in dmesg_uhci-first.

That log shows what was desired, at least 3-1 and 4-1 get disconnected
cleanly and I get no error messages to the console. Yay!

I added two extra printk's around the usb_wait_for_khubd_idle call to show
the exact effect of the wait (look for "khubd_idle" in two messages).
These seem to show what was wanted: both keyboard and mouse are detected
during the wait.

But it also shows a few events on bus 3 and 4 that happen after I get
khubd_idle that seem to indicate the probe on that bus is not completely
finished and that could maybe still cause "problems". But maybe I'm just
reading it wrong and those events are part of the lead up to the
disconnects for the hand-off.

Anyway, I'm quite happy with the result, so:
Tested-by: Frans Pop <[email protected]>


Last note FYI. I had another case of "dead keyboard" this morning, again
with the "reset low speed USB device" message in the log. Unfortunately
this was before I enabled USB debugging (and obviously before I had
applied the patch).
I will now revert the patch and keep USB debugging enabled to see if I can
catch this bug properly. I'll send the debug log when I do.

Cheers,
FJP


Attachments:
(No filename) (2.54 kB)
dmesg_ehci-first (41.83 kB)
dmesg_uhci-first (45.44 kB)
Download all attachments

2008-08-30 15:36:48

by Frans Pop

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (with debug log)

On Tuesday 26 August 2008, Alan Stern wrote:
> > Attached a full diff between dmesg from two consecutive boots: first
> > without keyboard; after reboot the keyboard is detected. The actual
> > difference is fairly small and clearly shows that usb 3-1 is not
> > handed off correctly, probably due to a small difference in timing.
> >
> > Note that I've never seen this problem with earlier kernels.
>
> I can't tell exactly what's going on because your usbcore module wasn't
> built with CONFIG_USB_DEBUG enabled.

I got lucky on the second boot with -rc5 and USB_DEBUG enabled.
Attached the output of dmesg. After this boot the keyboard was dead and
the telltale "reset low speed USB device" message is present.

Cheers,
FJP


Attachments:
(No filename) (729.00 B)
dmesg_no-keyboard_debug (41.81 kB)
Download all attachments

2008-08-31 02:21:32

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot

On Sat, 30 Aug 2008, Frans Pop wrote:

> The patch seems to do exactly what I was looking for! Details further
> down, but first some other comments.
>
>
> My first boot with your patch was with brltty still enabled. The log
> showed the right result, but I wanted to get a cleaner log without all
> the USB suspend/resume noise caused by brltty. So I disabled brltty's
> init script and rebooted.
>
> This gave a totally unexpected result: ehci now got loaded and initialized
> _before_ uhci which of course avoids the problem altogether (see attached
> log: dmesg_ehci-first). So apparently brltty's init script was
> responsible not only for the suspend/resume noise, but also influenced
> the load order of the two USB drivers.
> And apparently when things are left alone ehci _will_ be loaded before
> uhci, but that does not match what you described in earlier mails as it
> means the PCI bus order isn't followed. Confusing...

It _is_ confusing. There's so much going on at boot time, with tons of
processes all trying to run at once... Small changes can have
unexpectedly large effects.

What I said before was that the UHCI controllers are discovered and
registered before the EHCI controller. That's different from the order
in which the drivers are loaded, however; driver loading is managed
by the hotplug infrastructure in userspace, which is outside the
kernel's control. If your drivers had been built into the kernel
instead of as separate modules, then they would be probed in order of
discovery -- which would mean ehci-hcd would _always_ come after
uhci-hcd, not what you want.

(Actually even this might not be true any more. There are patches in
development which make certain parts of the kernel initialization,
including driver probing, run in parallel threads rather than
serially.)

> Anyway, this meant that to test your patch I had to try to get uhci to
> load first again. This turned out to be simple: just adding uhci_hcd
> in /etc/modules did the trick. The result is in dmesg_uhci-first.
>
> That log shows what was desired, at least 3-1 and 4-1 get disconnected
> cleanly and I get no error messages to the console. Yay!
>
> I added two extra printk's around the usb_wait_for_khubd_idle call to show
> the exact effect of the wait (look for "khubd_idle" in two messages).
> These seem to show what was wanted: both keyboard and mouse are detected
> during the wait.

So it worked as intended.

> But it also shows a few events on bus 3 and 4 that happen after I get
> khubd_idle that seem to indicate the probe on that bus is not completely
> finished and that could maybe still cause "problems". But maybe I'm just
> reading it wrong and those events are part of the lead up to the
> disconnects for the hand-off.

Both statements are correct. The initialization of the devices on
buses 3 and 4 _was_ complete. But the drivers were loaded later, so
driver probing and/or normal driver operation were in progress when
ehci-hcd interrupted things. Initialization != probing.

Remember what I said earlier, that EHCI initialization would interfere
with _any_ ongoing operations on the companion controllers? Now you're
seeing that effect in action.

> Anyway, I'm quite happy with the result, so:
> Tested-by: Frans Pop <[email protected]>

I still regard this more as a band-aid than anything else. In fact, it
should (in theory) be _safer_ to interrupt things during device
initialization than later, after the driver has started up. So I'm not
at all certain the patch should be merged.

Tomorrow I'll try asking for comments from other people on the mailing
list...

Alan Stern

2008-08-31 02:54:00

by Alan Stern

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot (with debug log)

On Sat, 30 Aug 2008, Frans Pop wrote:

> On Tuesday 26 August 2008, Alan Stern wrote:
> > > Attached a full diff between dmesg from two consecutive boots: first
> > > without keyboard; after reboot the keyboard is detected. The actual
> > > difference is fairly small and clearly shows that usb 3-1 is not
> > > handed off correctly, probably due to a small difference in timing.
> > >
> > > Note that I've never seen this problem with earlier kernels.
> >
> > I can't tell exactly what's going on because your usbcore module wasn't
> > built with CONFIG_USB_DEBUG enabled.
>
> I got lucky on the second boot with -rc5 and USB_DEBUG enabled.
> Attached the output of dmesg. After this boot the keyboard was dead and
> the telltale "reset low speed USB device" message is present.

Okay, now I can tell what happened.

It's kind of amusing. You ran across a side effect of some new code I
added fairly recently. The new code was supposed to make device
operation _more_ reliable! But in your case it backfired. :-(

Here's the story. As you'd expect, ehci-hcd initialization interrupted
the keyboard probing procedure. The interruption occurred just before
the point where the keyboard was configured. As a result the
configuration was not installed, but this isn't a fatal error and the
kernel continued normally.

It turns out that the EHCI init had finished and the keyboard's
connection was handed back to the UHCI controller before the hub driver
got around to noticing the disconnection. Here's where the new code
came into play. The idea is to prevent transient errors from causing
lasting effects -- if the hub driver sees that a device _was_
disconnected but after a hundred ms or so the same device appears to be
plugged in to the same port as before, it resets the device and
otherwise leaves it alone. In particular it does not treat the event
as a regular disconnection. That's exactly what happened to you: EHCI
init caused the keyboard to be disconnected from the UHCI controller,
and it was reconnected again by the time the hub driver looked at it.

That's why there was no "USB disconnect" message and there was a "reset
low speed USB device" instead. The end effect was that the _same_
instantiation of the keyboard device remained present, and since it had
never been configured, of course it didn't work.

This odd scenario might provide a valid reason for accepting the new
patch. Or on the other hand, it might provide a reason for removing
the "ignore transient disconnect" changes. At this point I'm not sure
what's best.

Alan Stern

2008-08-31 05:21:46

by Greg KH

[permalink] [raw]
Subject: Re: [regression] usb: sometimes dead keyboard after boot

On Sat, Aug 30, 2008 at 10:21:20PM -0400, Alan Stern wrote:
> (Actually even this might not be true any more. There are patches in
> development which make certain parts of the kernel initialization,
> including driver probing, run in parallel threads rather than
> serially.)

No, that did go in for one kernel release and then ripped out, it turned
out to not save any time and just cause lots more problems. So don't
worry about this.

thanks,

greg k-h