Runaway loop with the current git.
Subsystems (2)
Hi.
I've built current (aaad07763) git tree with config, which worked ok with 2.6.27 (pressed enter several times when 'make oldconfig' asked) and now system fails to boot.
Attached screen dump and config.
I'm not subscribed, please add to copy.
Thank you.
Signature · 1 line
Evgeniy Polyakov
#
# Automatically generated make config: don't edit # Linux kernel version: 2.6.28-rc7
# Fri Dec 5 20:38:12 2008
#
# CONFIG_64BIT is not setCONFIG_X86_32=y
# CONFIG_X86_64 is not setCONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_TIME=yCONFIG_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=yCONFIG_MMU=yCONFIG_ZONE_DMA=yCONFIG_GENERIC_ISA_DMA=yCONFIG_GENERIC_IOMAP=yCONFIG_GENERIC_BUG=yCONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=yCONFIG_X86_SMP=yCONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_32_SMP=yCONFIG_X86_HT=yCONFIG_X86_BIOS_REBOOT=yCONFIG_X86_TRAMPOLINE=yCONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#CONFIG_EXPERIMENTAL=yCONFIG_LOCK_KERNEL=yCONFIG_INIT_ENV_ARG_LIMIT=32CONFIG_LOCALVERSION="-mainline"
# CONFIG_LOCALVERSION_AUTO is not setCONFIG_SWAP=yCONFIG_SYSVIPC=yCONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not setCONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not setCONFIG_HAVE_UNSTABLE_SCHED_CLOCK=yCONFIG_GROUP_SCHED=yCONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not setCONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not setCONFIG_SYSFS_DEPRECATED=yCONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not setCONFIG_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 setCONFIG_BLK_DEV_INITRD=yCONFIG_INITRAMFS_SOURCE=""CONFIG_CC_OPTIMIZE_FOR_SIZE=yCONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not setCONFIG_UID16=yCONFIG_SYSCTL_SYSCALL=yCONFIG_KALLSYMS=yCONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not setCONFIG_HOTPLUG=yCONFIG_PRINTK=yCONFIG_BUG=yCONFIG_ELF_CORE=yCONFIG_PCSPKR_PLATFORM=yCONFIG_COMPAT_BRK=yCONFIG_BASE_FULL=yCONFIG_FUTEX=yCONFIG_ANON_INODES=yCONFIG_EPOLL=yCONFIG_SIGNALFD=yCONFIG_TIMERFD=yCONFIG_EVENTFD=yCONFIG_SHMEM=yCONFIG_AIO=yCONFIG_VM_EVENT_COUNTERS=yCONFIG_PCI_QUIRKS=yCONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not setCONFIG_PROFILING=y
# CONFIG_MARKERS is not setCONFIG_OPROFILE=m
# CONFIG_OPROFILE_IBS is not setCONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not setCONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=yCONFIG_HAVE_IOREMAP_PROT=yCONFIG_HAVE_KPROBES=yCONFIG_HAVE_KRETPROBES=yCONFIG_HAVE_ARCH_TRACEHOOK=yCONFIG_HAVE_GENERIC_DMA_COHERENT=yCONFIG_SLABINFO=yCONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not setCONFIG_BASE_SMALL=0CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not setCONFIG_MODULE_UNLOAD=yCONFIG_MODULE_FORCE_UNLOAD=yCONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not setCONFIG_KMOD=yCONFIG_STOP_MACHINE=yCONFIG_BLOCK=yCONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not setCONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not setCONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not setCONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not setCONFIG_DEFAULT_IOSCHED="cfq"CONFIG_CLASSIC_RCU=y
# CONFIG_FREEZER is not set
#
# Processor type and features
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not setCONFIG_GENERIC_CLOCKEVENTS_BUILD=yCONFIG_SMP=yCONFIG_X86_FIND_SMP_CONFIG=yCONFIG_X86_MPPARSE=yCONFIG_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_X86_RDC321X is not setCONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not setCONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not setCONFIG_X86_GENERIC=yCONFIG_X86_CPU=yCONFIG_X86_CMPXCHG=yCONFIG_X86_L1_CACHE_SHIFT=7CONFIG_X86_XADD=yCONFIG_X86_PPRO_FENCE=yCONFIG_X86_WP_WORKS_OK=yCONFIG_X86_INVLPG=yCONFIG_X86_BSWAP=yCONFIG_X86_POPAD_OK=yCONFIG_X86_INTEL_USERCOPY=yCONFIG_X86_USE_PPRO_CHECKSUM=yCONFIG_X86_TSC=yCONFIG_X86_CMOV=yCONFIG_X86_MINIMUM_CPU_FAMILY=4CONFIG_X86_DEBUGCTLMSR=yCONFIG_CPU_SUP_INTEL=yCONFIG_CPU_SUP_CYRIX_32=yCONFIG_CPU_SUP_AMD=yCONFIG_CPU_SUP_CENTAUR_32=yCONFIG_CPU_SUP_TRANSMETA_32=yCONFIG_CPU_SUP_UMC_32=yCONFIG_X86_DS=yCONFIG_X86_PTRACE_BTS=yCONFIG_HPET_TIMER=yCONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not setCONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
# CONFIG_SCHED_MC is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not setCONFIG_PREEMPT=y
# CONFIG_PREEMPT_RCU is not setCONFIG_X86_LOCAL_APIC=yCONFIG_X86_IO_APIC=yCONFIG_X86_MCE=yCONFIG_X86_MCE_NONFATAL=mCONFIG_X86_MCE_P4THERMAL=yCONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not setCONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not setCONFIG_PAGE_OFFSET=0xC0000000CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not setCONFIG_ARCH_FLATMEM_ENABLE=yCONFIG_ARCH_SPARSEMEM_ENABLE=yCONFIG_ARCH_SELECT_MEMORY_MODEL=yCONFIG_SELECT_MEMORY_MODEL=yCONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not setCONFIG_FLATMEM=yCONFIG_FLAT_NODE_MEM_MAP=yCONFIG_SPARSEMEM_STATIC=yCONFIG_PAGEFLAGS_EXTENDED=yCONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_PHYS_ADDR_T_64BIT is not setCONFIG_ZONE_DMA_FLAG=1CONFIG_BOUNCE=yCONFIG_VIRT_TO_BUS=yCONFIG_UNEVICTABLE_LRU=y
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not setCONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not setCONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
# CONFIG_X86_PAT is not set
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not setCONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not setCONFIG_HZ=250
# CONFIG_SCHED_HRTICK is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not setCONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not setCONFIG_PHYSICAL_ALIGN=0x100000CONFIG_HOTPLUG_CPU=yCONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not setCONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not setCONFIG_ACPI=yCONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not setCONFIG_ACPI_SYSFS_POWER=yCONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_DOCK is not setCONFIG_ACPI_PROCESSOR=mCONFIG_ACPI_HOTPLUG_CPU=yCONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not setCONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not setCONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not setCONFIG_ACPI_SYSTEM=yCONFIG_X86_PM_TIMER=yCONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not setCONFIG_PCI_GOANY=yCONFIG_PCI_BIOS=yCONFIG_PCI_DIRECT=yCONFIG_PCI_MMCONFIG=yCONFIG_PCI_DOMAINS=yCONFIG_PCIEPORTBUS=yCONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not setCONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_HT_IRQ is not setCONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not setCONFIG_HAVE_AOUT=yCONFIG_BINFMT_AOUT=mCONFIG_BINFMT_MISC=mCONFIG_HAVE_ATOMIC_IOMAP=yCONFIG_NET=y
#
# Networking options
#CONFIG_PACKET=yCONFIG_PACKET_MMAP=yCONFIG_UNIX=yCONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not setCONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not setCONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set CONFIG_INET_DIAG=mCONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not setCONFIG_IPV6=mCONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not setCONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_QUEUE is not setCONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not setCONFIG_IP_NF_FILTER=m
# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
# CONFIG_WIRELESS is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not setCONFIG_FW_LOADER=yCONFIG_FIRMWARE_IN_KERNEL=yCONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not setCONFIG_CONNECTOR=m
# CONFIG_MTD is not set
# CONFIG_PARPORT is not setCONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set
#
# Protocols
#CONFIG_PNPACPI=yCONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not setCONFIG_BLK_DEV_LOOP=mCONFIG_BLK_DEV_CRYPTOLOOP=mCONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not setCONFIG_BLK_DEV_RAM=yCONFIG_BLK_DEV_RAM_COUNT=16CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not setCONFIG_HAVE_IDE=yCONFIG_IDE=m
#
# Please see Documentation/ide/ide.txt for help/info on IDE drives #
# CONFIG_BLK_DEV_IDE_SATA is not setCONFIG_IDE_GD=mCONFIG_IDE_GD_ATA=y
# CONFIG_IDE_GD_ATAPI is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set
#
# 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 is not setCONFIG_BLK_DEV_IDEDMA_SFF=y
#
# PCI IDE chipsets support
#CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_OFFBOARD is not setCONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not setCONFIG_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_CS5535 is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not setCONFIG_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 setCONFIG_BLK_DEV_IDEDMA=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not setCONFIG_MD=yCONFIG_BLK_DEV_MD=mCONFIG_MD_LINEAR=mCONFIG_MD_RAID0=mCONFIG_MD_RAID1=mCONFIG_MD_RAID10=mCONFIG_MD_RAID456=mCONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not setCONFIG_MD_FAULTY=mCONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not setCONFIG_DM_CRYPT=mCONFIG_DM_SNAPSHOT=mCONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# Enable only one of the two stacks, unless you know what you are doing #
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not setCONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not setCONFIG_NET_ETHERNET=yCONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not setCONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set CONFIG_8139TOO_TUNE_TWISTER=yCONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_ATL2 is not set
# CONFIG_NETDEV_1000 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
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not setCONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not setCONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not setCONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not setCONFIG_INPUT_MOUSEDEV_SCREEN_X=1024CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#CONFIG_INPUT_KEYBOARD=yCONFIG_KEYBOARD_ATKBD=yCONFIG_KEYBOARD_SUNKBD=mCONFIG_KEYBOARD_LKKBD=mCONFIG_KEYBOARD_XTKBD=mCONFIG_KEYBOARD_NEWTON=m
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#CONFIG_SERIO=yCONFIG_SERIO_I8042=yCONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not setCONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#CONFIG_VT=yCONFIG_CONSOLE_TRANSLATIONS=yCONFIG_VT_CONSOLE=yCONFIG_HW_CONSOLE=yCONFIG_VT_HW_CONSOLE_BINDING=yCONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#CONFIG_SERIAL_8250=yCONFIG_SERIAL_8250_CONSOLE=yCONFIG_FIX_EARLYCON_MEM=yCONFIG_SERIAL_8250_PCI=yCONFIG_SERIAL_8250_PNP=yCONFIG_SERIAL_8250_NR_UARTS=16CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#CONFIG_SERIAL_CORE=yCONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not setCONFIG_UNIX98_PTYS=yCONFIG_LEGACY_PTYS=yCONFIG_LEGACY_PTY_COUNT=16
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not setCONFIG_GEN_RTC=mCONFIG_GEN_RTC_X=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not setCONFIG_DEVPORT=y
# CONFIG_I2C is not set
# CONFIG_SPI is not setCONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not setCONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not setCONFIG_THERMAL=y
# CONFIG_WATCHDOG is not setCONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_REGULATOR 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=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not setCONFIG_AGP_INTEL=m
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not setCONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not setCONFIG_DRM_I810=mCONFIG_DRM_I830=mCONFIG_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 is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not setCONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not setCONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not setCONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not setCONFIG_STAGING_EXCLUDE_BUILD=y
#
# Firmware Drivers
#
# CONFIG_EDD is not setCONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#CONFIG_EXT2_FS=mCONFIG_EXT2_FS_XATTR=yCONFIG_EXT2_FS_POSIX_ACL=yCONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not setCONFIG_EXT3_FS=mCONFIG_EXT3_FS_XATTR=yCONFIG_EXT3_FS_POSIX_ACL=yCONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4_FS is not setCONFIG_JBD=mCONFIG_FS_MBCACHE=m
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not setCONFIG_FS_POSIX_ACL=yCONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_DNOTIFY is not setCONFIG_INOTIFY=yCONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#CONFIG_PROC_FS=yCONFIG_PROC_KCORE=yCONFIG_PROC_SYSCTL=yCONFIG_PROC_PAGE_MONITOR=yCONFIG_SYSFS=yCONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# 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_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 is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not setCONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set
#
# Kernel hacking
#CONFIG_TRACE_IRQFLAGS_SUPPORT=yCONFIG_PRINTK_TIME=yCONFIG_ENABLE_WARN_DEPRECATED=yCONFIG_ENABLE_MUST_CHECK=yCONFIG_FRAME_WARN=1024CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not setCONFIG_DEBUG_KERNEL=yCONFIG_DEBUG_SHIRQ=yCONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not setCONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0CONFIG_SCHED_DEBUG=yCONFIG_SCHEDSTATS=yCONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not setCONFIG_DEBUG_SLAB=yCONFIG_DEBUG_SLAB_LEAK=yCONFIG_DEBUG_PREEMPT=yCONFIG_DEBUG_RT_MUTEXES=yCONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not setCONFIG_DEBUG_SPINLOCK=yCONFIG_DEBUG_MUTEXES=yCONFIG_DEBUG_LOCK_ALLOC=yCONFIG_PROVE_LOCKING=yCONFIG_LOCKDEP=yCONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not setCONFIG_TRACE_IRQFLAGS=yCONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not setCONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not setCONFIG_DEBUG_HIGHMEM=yCONFIG_DEBUG_BUGVERBOSE=yCONFIG_DEBUG_INFO=yCONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not setCONFIG_DEBUG_MEMORY_INIT=yCONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not setCONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not setCONFIG_HAVE_FUNCTION_TRACER=yCONFIG_HAVE_DYNAMIC_FTRACE=yCONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not setCONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_STRICT_DEVMEM is not setCONFIG_X86_VERBOSE_BOOTUP=yCONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not setCONFIG_DEBUG_STACKOVERFLOW=yCONFIG_DEBUG_STACK_USAGE=yCONFIG_DEBUG_PAGEALLOC=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not setCONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not setCONFIG_4KSTACKS=yCONFIG_DOUBLEFAULT=y
# CONFIG_MMIOTRACE is not setCONFIG_IO_DELAY_TYPE_0X80=0CONFIG_IO_DELAY_TYPE_0XED=1CONFIG_IO_DELAY_TYPE_UDELAY=2CONFIG_IO_DELAY_TYPE_NONE=3CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not setCONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not setCONFIG_XOR_BLOCKS=mCONFIG_ASYNC_CORE=mCONFIG_ASYNC_MEMCPY=mCONFIG_ASYNC_XOR=mCONFIG_CRYPTO=y
#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not setCONFIG_CRYPTO_ALGAPI=yCONFIG_CRYPTO_AEAD=mCONFIG_CRYPTO_BLKCIPHER=mCONFIG_CRYPTO_HASH=mCONFIG_CRYPTO_RNG=mCONFIG_CRYPTO_MANAGER=m
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# 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 is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#CONFIG_CRYPTO_HMAC=m
# CONFIG_CRYPTO_XCBC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_MD4 is not setCONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not setCONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not setCONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
#
# Library routines
#CONFIG_BITREVERSE=yCONFIG_GENERIC_FIND_FIRST_BIT=yCONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not setCONFIG_CRC32=y
# CONFIG_CRC7 is not setCONFIG_LIBCRC32C=mCONFIG_PLIST=yCONFIG_HAS_IOMEM=yCONFIG_HAS_IOPORT=yCONFIG_HAS_DMA=y
Quoted 9 lines · On Fri, 5 Dec 2008 21:03:50 +0300 Evgeniy Polyakov <[email protected]> wrote:
Hi.
I've built current (
aaad07763) git tree with config, which worked ok with 2.6.27 (pressed enter several times when 'make oldconfig' asked) and now system fails to boot.Attached screen dump and config.
I'm not subscribed, please add to copy.
Your modprobe is for some reason triggering a load of /dev/ttyS* (ie the serial 8250 stuff) from within the module loading scripts. You'll need to debug the user space and work out why the loop is happening then it should be fairly easy to fix.
Alan
Quoted 7 lines · Alan Cox
Quoted 4 lines · On Fri, 5 Dec 2008 21:03:50 +0300 Evgeniy Polyakov <[email protected]> wrote:
I've built current (
aaad07763) git tree with config, which worked ok with 2.6.27 (pressed enter several times when 'make oldconfig' asked) and now system fails to boot.
Quoted 8 lines
Quoted 3 lines
Attached screen dump and config.
I'm not subscribed, please add to copy.
Your modprobe is for some reason triggering a load of
/dev/ttyS*(ie the serial 8250 stuff) from within the module loading scripts. You'll need to debug the user space and work out why the loop is happening then it should be fairly easy to fix.
Why do you think it's serial? 5-1 looks more like /dev/console.
This also seems to happen only in initramfs for people who see this. People say that compiling-in some modules (unfortunately they don't remember which) makes it work again.
Can this be some init order problem, that the /dev/console is not initialized but, we fork a process which tries to access it?
Kay
Quoted 5 lines · Kay Sievers
Quoted 4 lines
Your modprobe is for some reason triggering a load of
/dev/ttyS*(ie the serial 8250 stuff) from within the module loading scripts. You'll need to debug the user space and work out why the loop is happening then it should be fairly easy to fix.
Quoted 8 lines
Why do you think it's serial? 5-1 looks more like
/dev/console.This also seems to happen only in initramfs for people who see this. People say that compiling-in some modules (unfortunately they don't remember which) makes it work again.
Can this be some init order problem, that the
/dev/consoleis not initialized but, we fork a process which tries to access it?
Getting that the same userspace runs ok in 2.6.27 and config changes do not show immediate reason, I would blame some internal changes in some kernel subsystem. Why at first it infinitely loops in tty/console loading?
I can not run bisect, since reboot requires vnc and I'm far from fast channel. Build of the fresh tree with existing config takes almost one hour, but it should not be a major problem.
I can do bisection after the weekend, but can test some changes before machine froze with unsuccessful patch.
Signature · 1 line
Evgeniy Polyakov
Quoted 6 lines
I can not run bisect, since reboot requires vnc and I'm far from fast channel. Build of the fresh tree with existing config takes almost one hour, but it should not be a major problem.
I can do bisection after the weekend, but can test some changes before machine froze with unsuccessful patch.
I really have no idea what you are seeing so short of a bisect I've nothing to suggest.
Quoted 9 lines · Alan Cox
Quoted 6 lines
I can not run bisect, since reboot requires vnc and I'm far from fast channel. Build of the fresh tree with existing config takes almost one hour, but it should not be a major problem.
I can do bisection after the weekend, but can test some changes before machine froze with unsuccessful patch.
I really have no idea what you are seeing so short of a bisect I've nothing to suggest.
But if things would be in userspace, then it should be fired long ago with .27 kernel, no?
And what's with tty drivers? If kernel freezes there even if suddenly faulty userspace started to load them, where this can happen? Apparently it is not sleeping userspace since console does not respond to input.
Signature · 1 line
Evgeniy Polyakov
Quoted 11 lines · Evgeniy Polyakov
Quoted 9 lines · Alan Cox
Quoted 6 lines
I can not run bisect, since reboot requires vnc and I'm far from fast channel. Build of the fresh tree with existing config takes almost one hour, but it should not be a major problem.
I can do bisection after the weekend, but can test some changes before machine froze with unsuccessful patch.
I really have no idea what you are seeing so short of a bisect I've nothing to suggest.
Quoted 6 lines
But if things would be in userspace, then it should be fired long ago with .27 kernel, no?
And what's with tty drivers? If kernel freezes there even if suddenly faulty userspace started to load them, where this can happen? Apparently it is not sleeping userspace since console does not respond to input.
5-1 dev_t request looks like something in initramfs accesses /dev/console, but the driver for it is not properly initialized/registered that time, and the kernel module loader tries to load a module? The forked process might also try to access /dev/console again, and hence the loop?
Kay
Quoted 9 lines · Kay Sievers
Quoted 3 lines
And what's with tty drivers? If kernel freezes there even if suddenly faulty userspace started to load them, where this can happen? Apparently it is not sleeping userspace since console does not respond to input.
5-1
dev_trequest looks like something in initramfs accesses/dev/console, but the driver for it is not properly initialized/registered that time, and the kernel module loader tries to load a module? The forked process might also try to access/dev/consoleagain, and hence the loop?
But why system freezes? Is this init linking/__init calling order changes? I have all tty/8250 compiled in btw.
$ egrep -i "console|tty|8250" /tmp/.config # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=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 is not set # Non-8250 serial port support CONFIG_SERIAL_CORE_CONSOLE=y # Console display driver support CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y
Signature · 1 line
Evgeniy Polyakov
Quoted 5 lines · Evgeniy Polyakov
Quoted 4 lines · Kay Sievers
Quoted 3 lines
And what's with tty drivers? If kernel freezes there even if suddenly faulty userspace started to load them, where this can happen? Apparently it is not sleeping userspace since console does not respond to input.
Quoted 8 lines
Quoted 5 lines
5-1
dev_trequest looks like something in initramfs accesses/dev/console, but the driver for it is not properly initialized/registered that time, and the kernel module loader tries to load a module? The forked process might also try to access/dev/consoleagain, and hence the loop?But why system freezes? Is this init linking/__init calling order changes?
Can you add something like:
+++ b/kernel/kmod.c
@@ -108,6 +108,7 @@ int request_module(const char *fmt, ...)
return -ENOMEM;
} + printk("XXX call modprobe %s %s[%u]\n", module_name,current->comm, task_pid_nr(current));
It may show which process is looking for /dev/console and causes modprobe to run, and maybe we get an idea what's going on. It may at least show if it's a /dev/console problem.
Thanks,
Kay
Quoted 6 lines · Kay Sievers
Can you add something like:
+++b/kernel/kmod.c
@@ -108,6 +108,7 @@ intrequest_module(const char *fmt, ...)return -ENOMEM; }
Quoted 6 lines
+ printk("XXX call modprobe %s %s[%u]\n",
module_name,current->comm,task_pid_nr(current));It may show which process is looking for
/dev/consoleand causes modprobe to run, and maybe we get an idea what's going on. It may at least show if it's a/dev/consoleproblem.
Its a modprobe with different pids tries to load char-major-5 and char-major-5-1 in the infinite loop.
Signature · 1 line
Evgeniy Polyakov
Quoted 10 lines · Evgeniy Polyakov
Quoted 9 lines · Kay Sievers
Can you add something like:
+++b/kernel/kmod.c
@@ -108,6 +108,7 @@ intrequest_module(const char *fmt, ...)return -ENOMEM; }+ printk("XXX call modprobe %s %s[%u]\n",
module_name,current->comm,task_pid_nr(current));
Quoted 6 lines
Quoted 3 lines
It may show which process is looking for
/dev/consoleand causes modprobe to run, and maybe we get an idea what's going on. It may at least show if it's a/dev/consoleproblem.Its a modprobe with different pids tries to load char-major-5 and char-major-5-1 in the infinite loop.
So the loop is probably a modprobe itself that tries to access /dev/console. Is there a different argument for the very first modprobe which is called? Which may be the one that triggers the loop.
Kay
Quoted 3 lines · Kay Sievers
So the loop is probably a modprobe itself that tries to access
/dev/console. Is there a different argument for the very first modprobe which is called? Which may be the one that triggers the loop.
Hard to tell, I did not see anything but modprobe before and after runaway loop message, but it could be missed though, I will tell for sure only this Monday.
Signature · 1 line
Evgeniy Polyakov
Quoted 8 lines · Evgeniy Polyakov
Quoted 3 lines · Kay Sievers
So the loop is probably a modprobe itself that tries to access
/dev/console. Is there a different argument for the very first modprobe which is called? Which may be the one that triggers the loop.Hard to tell, I did not see anything but modprobe before and after runaway loop message, but it could be missed though, I will tell for sure only this Monday.
Sounds good.
It seems the /dev/console driver is registered only after all the pci, video, acpi, ... drivers, so it's not surprising, that if any of these driver in these subsystems calls request_module(), or a process in initramfs tries to access the "dead" /dev/console node, things will go wrong.
Thanks,
Kay
Quoted 10 lines · Kay Sievers
Quoted 8 lines · Evgeniy Polyakov
Quoted 3 lines · Kay Sievers
So the loop is probably a modprobe itself that tries to access
/dev/console. Is there a different argument for the very first modprobe which is called? Which may be the one that triggers the loop.Hard to tell, I did not see anything but modprobe before and after runaway loop message, but it could be missed though, I will tell for sure only this Monday.
Quoted 7 lines
Sounds good.
It seems the
/dev/consoledriver is registered only after all the pci, video, acpi, ... drivers, so it's not surprising, that if any of these driver in these subsystems callsrequest_module(), or a process in initramfs tries to access the "dead"/dev/consolenode, things will go wrong.
I don't know if it may have any bad side-effects. It moves the tty registration earlier, before we do pci, framebuffer, video, acpi registration.
It boots fine here with and without initramfs.
Maybe it makes the "dead" /dev/console in your initramfs working, then we at least know the problem.
Thanks,
Kay
drivers/char/tty_io.c +4 -16
@@ -3115,26 +3115,14 @@ void __init console_init(void) } } -static int __init tty_class_init (void ) +static struct cdev tty_cdev, console_cdev; + +static int __init tty_init (void ) { tty_class =class_create (THIS_MODULE ,"tty" );if (IS_ERR (tty_class))return PTR_ERR (tty_class); -return 0 ; -} - -postcore_initcall (tty_class_init); - -/* 3/2004 jmc: why do these devices exist? */ -static struct cdev tty_cdev, console_cdev; - -/* -* Ok, now we can initialize the rest of the tty devices and can count -* on memory allocations, interrupts etc.. -*/ -static int __init tty_init (void ) -{cdev_init (&tty_cdev, &tty_fops);if (cdev_add (&tty_cdev,MKDEV (TTYAUX_MAJOR ,0 ),1 ) ||register_chrdev_region (MKDEV (TTYAUX_MAJOR ,0 ),1 ,"/dev/tty" ) <0 )
@@ -3154,4 +3142,4 @@ static int __init tty_init(void)#endif return 0 ; } -module_init (tty_init); +postcore_initcall (tty_init);
Quoted 8 lines · Kay Sievers
I don't know if it may have any bad side-effects. It moves the tty registration earlier, before we do pci, framebuffer, video, acpi registration.
It boots fine here with and without initramfs.
Maybe it makes the "dead"
/dev/consolein your initramfs working, then we at least know the problem.
I will try this patch this Monday and report back the results.
Thank you.
Signature · 1 line
Evgeniy Polyakov
Quoted 11 lines · Evgeniy Polyakov
Quoted 8 lines · Kay Sievers
I don't know if it may have any bad side-effects. It moves the tty registration earlier, before we do pci, framebuffer, video, acpi registration.
It boots fine here with and without initramfs.
Maybe it makes the "dead"
/dev/consolein your initramfs working, then we at least know the problem.I will try this patch this Monday and report back the results.
I was able to reproduce it with the .config you attached, and running it in kvm.
It is caused by:
"modprobe cryptomgr" called from swapper[1]
This modprobe process does try to log an error, accesses /dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to support dev_t 5:1, which again runs modprobe, and ...
Setting CONFIG_CRYPTO_MANAGER=y makes it disapper. The patch I sent seems to fix it.
The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153
Thanks,
Kay
Quoted 5 lines · Kay Sievers
I was able to reproduce it with the .config you attached, and running it in kvm.
It is caused by:
"modprobe cryptomgr" called from swapper[1]
Quoted 7 lines
This modprobe process does try to log an error, accesses
/dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to supportdev_t5:1, which again runs modprobe, and ...Setting
CONFIG_CRYPTO_MANAGER=ymakes it disapper. The patch I sent seems to fix it.
Great to know it works. I will test it when get access to the machine after the weekend.
Quoted 1 line
The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153
There is a good point in the thread, that hotplug should not call recursion, but while this may be very valid requirement, it is _very_ subtle, and something more solid should be done. Just an opinion.
Initialization reordering is likely also not what we want, but simple dumb console (or just dummy device which will accept data and will be replaced later) sounds like a way to go, and your patch seems to allow that dumb class registration first.
I actually used to believe that it works that way already...
Signature · 1 line
Evgeniy Polyakov
Quoted 4 lines
This modprobe process does try to log an error, accesses
/dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to supportdev_t5:1, which again runs modprobe, and ...
So we have a buggy modprobe...
Quoted 5 lines
Setting
CONFIG_CRYPTO_MANAGER=ymakes it disapper. The patch I sent seems to fix it.The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153
We cannot go re-ordering random chunks of kernel init with unpredictable effects including possibly making other stuff less reliable (because you set up the console device before the console driver is loaded on a PCI bus device). And we certainly can't do it this close to a release.
Alan
Quoted 6 lines · Alan Cox
Quoted 4 lines
This modprobe process does try to log an error, accesses
/dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to supportdev_t5:1, which again runs modprobe, and ...So we have a buggy modprobe...
Which nevertheless should not break boot process...
Quoted 9 lines
Quoted 4 lines
Setting
CONFIG_CRYPTO_MANAGER=ymakes it disapper. The patch I sent seems to fix it.The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153
We cannot go re-ordering random chunks of kernel init with unpredictable effects including possibly making other stuff less reliable (because you set up the console device before the console driver is loaded on a PCI bus device). And we certainly can't do it this close to a release.
Alan, really, do you believe that relying on userspace to be always correct is the way to go? Requrement for the userspace to always have enough buffer available when doing some reading is essetually the same. We want userspace to be non-recursive, but if this does not happen, we should not hung. Detect recursion, do not allow more than 1-2-3 simultaneous modprobes, whatever, but do not say, that kernel behaves that bad just because userspace is allowed to do that.
And what's the argument of being close to a release? Do you propose to hide the head into the sand and point a finger to anyone else saying its not a kernel's problem? If prerelease has a bug, it should be fixed, and not hidden under the cover.
What about storing a small stack of recently requested device ids, and if new request is about to ask one from that stack, return error? I can cook up the patch tomorrow.
Signature · 1 line
Evgeniy Polyakov
Quoted 3 lines
Quoted 1 line
So we have a buggy modprobe...
Which nevertheless should not break boot process...
Now you are talking complete crap. If init crashes what happens. If I have the wrong root fs listed what happens ?
Gee it breaks. Early userspace actually does have to be correct.
Quoted 3 lines
should not hung. Detect recursion, do not allow more than 1-2-3 simultaneous modprobes, whatever, but do not say, that kernel behaves that bad just because userspace is allowed to do that.
Please read the code: that is what we do. That is *WHY* you got the runaway modprobe message. It was caught but despite that the broken initrd failed to recover. We've had that feature for years.
Quoted 4 lines
And what's the argument of being close to a release? Do you propose to hide the head into the sand and point a finger to anyone else saying its not a kernel's problem? If prerelease has a bug, it should be fixed, and not hidden under the cover.
Its an incredibly obscure corner case. It is not appropriate to totally trash years of kernel testing by panic re-ordering some init functions just before a release. You will undoubtedly harm more people than you'll please.
Quoted 3 lines
What about storing a small stack of recently requested device ids, and if new request is about to ask one from that stack, return error? I can cook up the patch tomorrow.
That would be an interesting experiment for 2.6.29 however we do requests in lots of different formats so it might be a bit more complex. You could store the last few strings. However the existing runaway code caught it and will have resulted in the -ENXIO path occuring anyway so I don't see what your "change" will achieve.
Alan
Quoted 6 lines · Alan Cox
Quoted 1 line
Which nevertheless should not break boot process...
Now you are talking complete crap. If init crashes what happens. If I have the wrong root fs listed what happens ?
Gee it breaks. Early userspace actually does have to be correct.
Heh, if userspace writes more than kernel's buffer size, what happens? We suddenly stopped to trust userspace? What if modprobe itself will do that? Do not differentiate bugs by the nature of not-bad and bad-enough:
we do not trust userspace, even init, and it looking at the very end of the mail you will find again why this loading crap is a kernel problem.
Quoted 7 lines
Quoted 3 lines
should not hung. Detect recursion, do not allow more than 1-2-3 simultaneous modprobes, whatever, but do not say, that kernel behaves that bad just because userspace is allowed to do that.
Please read the code: that is what we do. That is *WHY* you got the runaway modprobe message. It was caught but despite that the broken initrd failed to recover. We've had that feature for years.
Apparently just reading the code does not magically fix kernel problems. What's the cosmic rays should initird check when it is asked by kernel to load the module? It tries to load it, which in turn tries to load it again. Since initird does not use libastral yet, it is up to kernel to decide what to load and when to ask userspace about that.
Quoted 9 lines
Quoted 4 lines
And what's the argument of being close to a release? Do you propose to hide the head into the sand and point a finger to anyone else saying its not a kernel's problem? If prerelease has a bug, it should be fixed, and not hidden under the cover.
Its an incredibly obscure corner case. It is not appropriate to totally trash years of kernel testing by panic re-ordering some init functions just before a release. You will undoubtedly harm more people than you'll please.
Registering purely software class device not being backed by real hardware since appropriate buses are not yet available? Apparently I know how to fix this problem: I will write a simple console driver called 'prayer', which will just sacrifice a little CPU's heat to the Raa-god when anyone tries to write something to console. And this driver will later be replaced with real console. Ooops, doesn't above patch from Kay do the same?
Quoted 9 lines
Quoted 3 lines
What about storing a small stack of recently requested device ids, and if new request is about to ask one from that stack, return error? I can cook up the patch tomorrow.
That would be an interesting experiment for 2.6.29 however we do requests in lots of different formats so it might be a bit more complex. You could store the last few strings. However the existing runaway code caught it and will have resulted in the
-ENXIOpath occuring anyway so I don't see what your "change" will achieve.
It will not infinitely try to load module, which tries to load itself again via obscure kernel pathes, return error and continue.
I remind again: all console/tty stuff in my setup is built-in, so there should be no module request at all, but since earlier registered code does not know that, kernel believes that console is somewhere in the module. Having dumb device registered first is a fix for this problem.
Signature · 1 line
Evgeniy Polyakov
Quoted 6 lines · Alan Cox
Quoted 4 lines
This modprobe process does try to log an error, accesses
/dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to supportdev_t5:1, which again runs modprobe, and ...So we have a buggy modprobe...
No, we have not. It is fine for modprobe doing that, as it is for any other binary too. It's also the usual glibc behavior for syslog(). Any userspace binary can access /dev/console any time. The kernel is not supposed to call modprobe to make /dev/console availabe.
Quoted 9 lines
Quoted 4 lines
Setting
CONFIG_CRYPTO_MANAGER=ymakes it disapper. The patch I sent seems to fix it.The bug is handled here: http://bugzilla.kernel.org/show_bug.cgi?id=12153
We cannot go re-ordering random chunks of kernel init with unpredictable effects including possibly making other stuff less reliable (because you set up the console device before the console driver is loaded on a PCI bus device).
We are not reordering, we provide a registered /dev/console driver core device, not touching any driver, just to prevent the kernel module loader from going crazy.
Quoted 1 line
And we certainly can't do it this close to a release.
We can do the real fix any time it is the proper time. It is still an obvious kernel bug which needs to be fixed, and not some obscure userspace rule, we suddenly need to establish to work around some dumb module loader/console logic.
Thanks,
Kay
Quoted 4 lines
No, we have not. It is fine for modprobe doing that, as it is for any other binary too. It's also the usual glibc behavior for
syslog(). Any userspace binary can access/dev/consoleany time. The kernel is not supposed to call modprobe to make/dev/consoleavailabe.
Yes it is. The hotplug interface is designed to handle dynamic loading of devices including the console. Likewise your hard disk interfaces you can access at any time - guess what, those need loading too and if you put your modprobe on a disk you've not got a driver loaded for that doesn't work either.
Quoted 3 lines
We are not reordering, we provide a registered
/dev/consoledriver core device, not touching any driver, just to prevent the kernel module loader from going crazy.
You are reordering things.
The kernel module loader isn't going crazy either. The kernel module loader is doings its job. The userspace then goes silly and the kernel module loader correctly traps the problem, logs an error and tries to continue things, but the initrd is it seems too broken to handle that anyway.
Note that last small rather important detail - the kernel does detect runaway modprobe loops already.
Alan
Herbert Xu
maintainerQuoted 6 lines · Alan Cox
Quoted 4 lines
This modprobe process does try to log an error, accesses
/dev/console, which is not initialized in the kernel at that time, and the kernel module loader tries the load a module to supportdev_t5:1, which again runs modprobe, and ...So we have a buggy modprobe...
FWIW the crypto layer is doing what is intended. The algorithm testing infrastructure in the cryptomgr module is optional and only used when algorithms are registered. That's why it sits in its own module which is loaded by the algorithm registration code which still functions if the module is absent or fails to load.
In any case the loop itself does not involve any crypto components so I don't think making changes in the crypto layer is going to make this go away forever as anyone calling request_module early enough will get into this loop.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 4 lines
In any case the loop itself does not involve any crypto components so I don't think making changes in the crypto layer is going to make this go away forever as anyone calling
request_moduleearly enough will get into this loop.
Thanks - closed as WONTFIX as this is ultimately a user space bug caused by picking particularly odd combinations of configuration options (serial console, crypto testing) combined with a problem with someones specific initrd
Alan
Herbert Xu
maintainerQuoted 5 lines · Herbert Xu
In any case the loop itself does not involve any crypto components so I don't think making changes in the crypto layer is going to make this go away forever as anyone calling
request_moduleearly enough will get into this loop.
Having said that I think this patch should remove this particular trigger. Unfortunately I couldn't find a more succinct way of expressing this relationship: if ALGAPI is built-in because it's selected by an algorithm, and CRYPTO_MANAGER is enabled then we require CRYPTO_MANAGER to be built-in as well.
Evgeniy, please let me know whether this fixes the problem.
crypto/Kconfig +32 -4
@@ -31,35 +31,63 @@ config CRYPTO_FIPS config CRYPTO_ALGAPI tristate + select CRYPTO_ALGAPI2 help This option provides the API for cryptographic algorithms. +config CRYPTO_ALGAPI2 + tristate + config CRYPTO_AEAD tristate + select CRYPTO_AEAD2 select CRYPTO_ALGAPI +config CRYPTO_AEAD2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_BLKCIPHER tristate + select CRYPTO_BLKCIPHER2 select CRYPTO_ALGAPI - select CRYPTO_RNG + +config CRYPTO_BLKCIPHER2 + tristate + select CRYPTO_ALGAPI2 + select CRYPTO_RNG2 config CRYPTO_HASH tristate + select CRYPTO_HASH2 select CRYPTO_ALGAPI +config CRYPTO_HASH2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_RNG tristate + select CRYPTO_RNG2 select CRYPTO_ALGAPI +config CRYPTO_RNG2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_MANAGER tristate "Cryptographic algorithm manager" - select CRYPTO_AEAD - select CRYPTO_HASH - select CRYPTO_BLKCIPHER + select CRYPTO_MANAGER2 help Create default cryptographic template instantiations such as cbc(aes). +config CRYPTO_MANAGER2 + def_tristate CRYPTO_MANAGER || (CRYPTO_MANAGER!=n && CRYPTO_ALGAPI=y) + select CRYPTO_AEAD2 + select CRYPTO_HASH2 + select CRYPTO_BLKCIPHER2 + config CRYPTO_GF128MUL tristate "GF(2^128) multiplication functions (EXPERIMENTAL)" depends on EXPERIMENTAL
crypto/Makefile +7 -7
@@ -9,25 +9,25 @@ obj-$(CONFIG_CRYPTO_FIPS) += fips.o crypto_algapi-$(CONFIG_PROC_FS) += proc.o crypto_algapi-objs := algapi.o scatterwalk.o $(crypto_algapi-y) -obj-$(CONFIG_CRYPTO_ALGAPI) += crypto_algapi.o +obj-$(CONFIG_CRYPTO_ALGAPI2) += crypto_algapi.o -obj-$(CONFIG_CRYPTO_AEAD) += aead.o +obj-$(CONFIG_CRYPTO_AEAD2) += aead.o crypto_blkcipher-objs := ablkcipher.o crypto_blkcipher-objs += blkcipher.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += crypto_blkcipher.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += chainiv.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += eseqiv.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += crypto_blkcipher.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += chainiv.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += eseqiv.o obj-$(CONFIG_CRYPTO_SEQIV) += seqiv.o crypto_hash-objs := hash.o crypto_hash-objs += ahash.o crypto_hash-objs += shash.o -obj-$(CONFIG_CRYPTO_HASH) += crypto_hash.o +obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o cryptomgr-objs := algboss.o testmgr.o -obj-$(CONFIG_CRYPTO_MANAGER) += cryptomgr.o +obj-$(CONFIG_CRYPTO_MANAGER2) += cryptomgr.o obj-$(CONFIG_CRYPTO_HMAC) += hmac.o obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 7 lines · Herbert Xu
Quoted 5 lines · Herbert Xu
In any case the loop itself does not involve any crypto components so I don't think making changes in the crypto layer is going to make this go away forever as anyone calling
request_moduleearly enough will get into this loop.
Quoted 7 lines
Having said that I think this patch should remove this particular trigger. Unfortunately I couldn't find a more succinct way of expressing this relationship: if ALGAPI is built-in because it's selected by an algorithm, and
CRYPTO_MANAGERis enabled then we requireCRYPTO_MANAGERto be built-in as well.Evgeniy, please let me know whether this fixes the problem.
Even when this works around it, the problem that the kernel triggers module loading on /dev/console access stays and needs to be fixed instead.
It's a pure kernel bug, regardless of how many times Alan likes to establish non-sensical hotplug rules to prevent this. The next innocent driver change, like yours is, will run into the same problem.
Thanks,
Kay
Quoted 3 lines
Even when this works around it, the problem that the kernel triggers module loading on
/dev/consoleaccess stays and needs to be fixed instead.
It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen.
Alan
Quoted 6 lines · Alan Cox
Quoted 3 lines
Even when this works around it, the problem that the kernel triggers module loading on
/dev/consoleaccess stays and needs to be fixed instead.It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen.
No, it's not. 5:1 is _in_ the kernel, and must not be tried to be loaded by the kernel. We need to make /dev/console access return -ENODEV if not available, not try to load a module for it.
It is a problem. It's broken behavior, and it breaks shipped products with any innocent future driver change like Herbert's.
Please start to think about the problem, and don't repeat things that do not make sense, and never made any sense.
Thanks,
Kay
Quoted 6 lines
Quoted 2 lines
It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen.
No, it's not. 5:1 is _in_ the kernel, and must not be tried to be loaded by the kernel. We need to make
/dev/consoleaccess return-ENODEVif not available, not try to load a module for it.
Hello earth calling, wake up.
The userspace opens major 5 minor 1. The kernel has no driver mapped to that so the kernel asks user space to load a module of its choice for major 5 minor 1. What user space does with that is and has always been a problem for user space.
User space is quite at liberty to go .. 5,1 and I have a serial console I want to load 8250_pci please.
What it must not do is try and re-open it again and again and again.
You may not assume that a given device load mapping is solely used to create the most basic device node involved. It isn't that simple. In many cases a device node translates to a series of module loads of otherwise apparently unrelated devices.
Quoted 2 lines · Alan Cox
The userspace opens major 5 minor 1. The kernel has no driver mapped to that so the kernel asks user space to load a module of its choice for
It has. It really has it. It was not yet initialized though because, because, because... Hmm, userspace code started and built-in kernel subsystem was not yet initialized.
Quoted 7 lines
major 5 minor 1. What user space does with that is and has always been a problem for user space.
User space is quite at liberty to go .. 5,1 and I have a serial console I want to load 8250_pci please.
What it must not do is try and re-open it again and again and again.
Heh, init is not allowed to write something to the console or any other tty?
Signature · 1 line
Evgeniy Polyakov
Quoted 2 lines
Heh, init is not allowed to write something to the console or any other tty?
init is not run as the helper of a modprobe.
Quoted 4 lines · Alan Cox
Quoted 2 lines
Heh, init is not allowed to write something to the console or any other tty?
init is not run as the helper of a modprobe.
I hope it is not another limitation for the early userspace? :) I worked with systems where init made everything. Not showing that as an example of particulary good design, but still there may be situations when userspace code does something, which kernel is not ready for. And it is a kernel problem that it is not ready for some usespace behaviour.
Btw, modprobe can not print error message to the console, that's the rule ;)
Signature · 1 line
Evgeniy Polyakov
Quoted 6 lines · Alan Cox
Quoted 3 lines
Even when this works around it, the problem that the kernel triggers module loading on
/dev/consoleaccess stays and needs to be fixed instead.It isn't a problem. It is trying to have hotplug load a suitable driver. This is what is supposed to happen.
Wrong. First at least because tty/console stuff is built in. But we alredy got, that you decided that Debian's initramfs-tools (0.92e) are allowed not to boot with some kernel configs.
Signature · 1 line
Evgeniy Polyakov
Quoted 1 line
Wrong. First at least because tty/console stuff is built in.
Are you two people or just two names and email addresses for the same ?
/dev/console is a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.
Quoted 2 lines
But we alredy got, that you decided that Debian's initramfs-tools (0.92e) are allowed not to boot with some kernel configs.
Yes. They won't boot if you don't include any disk drivers. They won't boot if you don't include any file systems. They wont boot in a million other cases. That is the user space not the kernel at fault.
The kernel is doing precisely what it is supposed to. It is even logging the user space bug and stopping trying to get stuck in a loop loading a module in order to attempt to cope with the user space bug.
If you want to complain then file a debian bug, go fix the user space.
Alan
Quoted 4 lines · Alan Cox
Quoted 1 line
Wrong. First at least because tty/console stuff is built in.
Are you two people or just two names and email addresses for the same ?
Depending on who you are asking for.
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.
Yup. It may. But in showed case it is not. In showed case it showed a bug. Which you call a feature.
Quoted 6 lines
Quoted 2 lines
But we alredy got, that you decided that Debian's initramfs-tools (0.92e) are allowed not to boot with some kernel configs.
Yes. They won't boot if you don't include any disk drivers. They won't boot if you don't include any file systems. They wont boot in a million other cases. That is the user space not the kernel at fault.
But right now _everything_ is presented. All things are in places. Disk drivers, filesystem, and even that stupid console/tty driver. It _IS_ in the kernel.
Quoted 5 lines
The kernel is doing precisely what it is supposed to. It is even logging the user space bug and stopping trying to get stuck in a loop loading a module in order to attempt to cope with the user space bug.
If you want to complain then file a debian bug, go fix the user space.
You introduce so naive rules for the initramfs userspace... It should not use console, it should not load modules, which may load another one... What next, not to use syscalls? Sigh, instead of thinking on how to fix the weak boot process so that next time similar problem arises, we ended up with pointing a finger one to another... Hope we will not get another similar cases though.
Signature · 1 line
Evgeniy Polyakov
Quoted 4 lines · Alan Cox
Quoted 1 line
Wrong. First at least because tty/console stuff is built in.
Are you two people or just two names and email addresses for the same ?
Damn, now you found that out.
I suggest you get a few more mail addresses too, to back your non-sensical claims, and try to establish silly userspace rules to work around an obvious kernel bug. :)
Good luck, looking forward to your creativity,
Kay
Quoted 7 lines · Alan Cox
Quoted 1 line
Wrong. First at least because tty/console stuff is built in.
Are you two people or just two names and email addresses for the same ?
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.
So wrong. If no driver is associated, like early, in that case, we must return -ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.
Again, please start to think about, it's all contained in the kernel, and the kernel is wrong. Claiming userspace is guilty to triggering this kernel bug does not help anything.
Kay
Quoted 6 lines
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.So wrong. If no driver is associated, like early, in that case, we must return
-ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.
You've clearly no idea how initrd even works have you ? If it just returned -ENODEV you wouldn't be able to open the console and you wouldn't trigger the loading of the module to get the console running. So you've now completely buggered the boot process.
The correct sequence is
Open device
Kernel issues hotplug message
Hotplug script loads drivers to policy
The problem case you have due to initrd bugs is
Open device
Kernel issues hotplug message
Hotplug script opens same device (BUG)
Kernel issues hotplug message
.....
Kernel detects this is stuck Kernel replies with -ENODEV/-ENXIO to try
and rescue itself from buggy initrd scripts
That is how it has worked since we first had script based module requesting which is some years now.
Quoted 8 lines · Alan Cox
Quoted 6 lines
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.So wrong. If no driver is associated, like early, in that case, we must return
-ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.You've clearly no idea how initrd even works have you ?
Not sure, if you understand the real problem. A kernel forked binary is allowed to access /dev/console, but it triggers a kernel bug.
Quoted 4 lines
If it just
returned-ENODEVyou wouldn't be able to open the console and you wouldn't trigger the loading of the module to get the console running. So you've now completely buggered the boot process.
Utter nonsense. Exactly when the driver is available shortly later, the console will work. If it's not backed by a driver, it should not try to load it, it will never get any driver loaded by opening it. The kernel must handle that.
Quoted 5 lines
The correct sequence is
Open device
Kernel issues hotplug message
Hotplug script loads drivers to policy
Nonsense. The kernel calls /sbin/modprobe directly, no hotplug involved.
Quoted 5 lines
The problem case you have due to initrd bugs is
Open device
Kernel issues hotplug message
Hotplug script opens same device (BUG)
The kernel calls modprobe for something, modprobe tries to log an error, and the kernel calls modprobe again. Bug! No hotplug involved.
Quoted 5 lines
Kernel issues hotplug message
.....
Kernel detects this is stuck Kernel replies with -ENODEV/-ENXIO to try
and rescue itself from buggy initrd scripts
Totally wrong, It never was that way.
Quoted 2 lines
That is how it has worked since we first had script based module requesting which is some years now.
Please update your idea of hotplug and the kernel module loader, you are on the totally wrong track.
Thanks,
Kay
Quoted 4 lines · On Sun, 7 Dec 2008 18:39:48 +0100 "Kay Sievers" <[email protected]> wrote:
Quoted 3 lines · Alan Cox
Quoted 3 lines
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
So wrong. If no driver is associated, like early, in that case, we must return
-ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.You've clearly no idea how initrd even works have you ?
Not sure, if you understand the real problem. A kernel forked binary is allowed to access
/dev/console, but it triggers a kernel bug.
If there is a hotplug load for the console device then it cannot. Just as a request for the driver for /dev/hda cannot open /dev/hda* again.
Quoted 1 line
Nonsense. The kernel calls
/sbin/modprobedirectly, no hotplug involved.
Its up to you if the kernel calls modprobe and what your modprobe is
Quoted 2 lines
The kernel calls modprobe for something, modprobe tries to log an error, and the kernel calls modprobe again. Bug! No hotplug involved.
A modprobe to load the console device shouln't open /dev/console. Very simple and always been true.
Quoted 7 lines
Quoted 5 lines
Kernel issues hotplug message
.....
Kernel detects this is stuck Kernel replies with -ENODEV/-ENXIO to try
and rescue itself from buggy initrd scriptsTotally wrong, It never was that way
Funny but its been that way for many many years. Just as it cannot try and syslog an error when loading the AF_UNIX socket family.
Alan
Quoted 11 lines · Alan Cox
Quoted 8 lines · On Sun, 7 Dec 2008 18:39:48 +0100 "Kay Sievers" <[email protected]> wrote:
Quoted 7 lines · Alan Cox
Quoted 6 lines
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.So wrong. If no driver is associated, like early, in that case, we must return
-ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
You've clearly no idea how initrd even works have you ?
Not sure, if you understand the real problem. A kernel forked binary is allowed to access
/dev/console, but it triggers a kernel bug.If there is a hotplug load for the console device then it cannot. Just as a request for the driver for
/dev/hdacannot open/dev/hda*again.
So wrong. Modprobe 5:1 will never load anything, but kill the box in such case at that time of bootup.
Quoted 3 lines
Quoted 1 line
Nonsense. The kernel calls
/sbin/modprobedirectly, no hotplug involved.Its up to you if the kernel calls modprobe and what your modprobe is
What are you saying? Your picture of hotplug is just wrong, regardless of "it's up to you". I talk about what people use, and what is obviously broken currently.
Quoted 5 lines
Quoted 2 lines
The kernel calls modprobe for something, modprobe tries to log an error, and the kernel calls modprobe again. Bug! No hotplug involved.
A modprobe to load the console device shouln't open
/dev/console. Very simple and always been true.
We are _not_ loading a console driver that way, we try to load the console device itself, not the driver. There is no driver for 5:1 in any module.
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
Kernel issues hotplug message
.....
Kernel detects this is stuck Kernel replies with -ENODEV/-ENXIO to try
and rescue itself from buggy initrd scriptsTotally wrong, It never was that way
Funny but its been that way for many many years. Just as it cannot try and syslog an error when loading the
AF_UNIXsocket family.
And? Keep on the subject please. It's still a bug to run in a loop trying something that will _never_ exist.
Kay
Quoted 3 lines · Kay Sievers
We are _not_ loading a console driver that way, we try to load the console device itself, not the driver. There is no driver for 5:1 in any module.
Semantic quibbling, trying to paper over stupidity.
It doesn't really matter if it's a "console driver" or "the console device itself". If you're in modprobe loading *any* piece of "all the stuff needed to make open("/dev/console") work", the last thing you want to be doing is opening /dev/console to complain about something not working.
As Alan said several times now, there really *is* a requirement that early userspace has its act together.
Quoted 5 lines · On Mon, Dec 8, 2008 at 04:23, <[email protected]> wrote:
Quoted 3 lines · Kay Sievers
We are _not_ loading a console driver that way, we try to load the console device itself, not the driver. There is no driver for 5:1 in any module.
[childish blurb removed]
Quoted 4 lines
It doesn't really matter if it's a "console driver" or "the console device itself". If you're in modprobe loading *any* piece of "all the stuff needed to make
open("/dev/console")work", the last thing you want to be doing is opening/dev/consoleto complain about something not working.
Nothing in initramfs or userspace tries to load "all the stuff needed to make open("/dev/console") work". It's the kernel itself, that tries to resolve its own requirements.
The kernel forked binary _writes_ to /dev/console, if we like it or not, it seems to do that, and it's arguable why it should not, or how it should detect that it is not allowed to do that. You may just depend on the logging of binaries to find other bugs.
The helper was called in the first place for something else, in this case the "cryptomgr". The loop is caused entirely by the kernel itself, if /dev/console is just accessed. There is no intentional loading of any console driver from userspace happening here.
Kay
Quoted 19 lines · Alan Cox
Quoted 6 lines
Quoted 2 lines
/dev/consoleis a logical mapping to a device which may well be different, loaded after PCI is initialised and dependant on PCI.So wrong. If no driver is associated, like early, in that case, we must return
-ENODEV, instead of calling modprobe in a loop. It's a built-in device, and it's easy to fix.You've clearly no idea how initrd even works have you ? If it just returned
-ENODEVyou wouldn't be able to open the console and you wouldn't trigger the loading of the module to get the console running. So you've now completely buggered the boot process.The correct sequence is
Open device
Kernel issues hotplug message
Hotplug script loads drivers to policy
Quoted 5 lines
The problem case you have due to initrd bugs is
Open device
Kernel issues hotplug message
Hotplug script opens same device (BUG)
Everyone understands that, what you do not want to get, is that this case can be handled by the kernel so that there would be no recursion. And instead of thinking how to fix it, you just try to shut it up.
There may be another case, when the same happens inside the kernel, i.e. module being loaded requires console and the same happens again. Similar problem exists for network console, when there is no underlying device yet, but it is handled.
Fortunately console is the most common example (maybe even the only one), so this case can be fixed easily. Moreover, because of subtle tty ordering, when everything is in kernel, it still may be triggered, as was shown previously.
And while having dumb console device sounds awful for you, it is a bulletprof solution even for non-expected userspace behaviout. And so far the only objection was that it may break something, which you believe may happen not even being tested.
Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts?
Signature · 1 line
Evgeniy Polyakov
Quoted 4 lines
Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts?
I have no intention of applying Kay's patch because it is wrong and it will only break things not fix them.
Alan
Quoted 7 lines · Alan Cox
Quoted 4 lines
Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts?
I have no intention of applying Kay's patch because it is wrong and it will only break things not fix them.
And you are sure it breaks something based on what?
Signature · 1 line
Evgeniy Polyakov
Quoted 10 lines · On Sun, 7 Dec 2008 20:54:38 +0300 Evgeniy Polyakov <[email protected]> wrote:
Quoted 7 lines · Alan Cox
Quoted 4 lines
Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts?
I have no intention of applying Kay's patch because it is wrong and it will only break things not fix them.
And you are sure it breaks something based on what?
Firstly:
You propose to implement
modprobe fails (due to crypto requirements) open /dev/console
-ENODEV
log error to nowhere
Why is this useful - you now get failing module loads producing no diagnostics and in many case the setup just dying silently. Previously you got an attempt to recover and diagnostics which allowed the problem to be found (as Herbert did)
Secondly:
If I have a /dev/console on a PCI device and I have modprobe set to load 8250_pci or a framebuffer driver when the console is opened you will break the current working behaviour.
Quoted 15 lines · Alan Cox
Quoted 10 lines · On Sun, 7 Dec 2008 20:54:38 +0300 Evgeniy Polyakov <[email protected]> wrote:
Quoted 7 lines · Alan Cox
Quoted 4 lines
Alan, let's make some progress on this fingerpointing. If Herbert's patch fixes the crypto loading problem, it will find its way upstream for the current tree, and in the merge window Kay's patch may be applied and widely tested. Thoughts?
I have no intention of applying Kay's patch because it is wrong and it will only break things not fix them.
And you are sure it breaks something based on what?
Quoted 8 lines
Firstly:
You propose to implement
modprobe fails (due to crypto requirements) open
/dev/console
-ENODEV
log error to nowhere
Yes, log nowhere instead of running in a loop would be much better than loading a 5:1 driver which will never exist as a module.
Quoted 2 lines
Why is this useful - you now get failing module loads producing no diagnostics and in many case the setup just dying silently.
It's obviously more useful than not to boot up.
Quoted 9 lines
Previously
you got an attempt to recover and diagnostics which allowed the problem to be found (as Herbert did)Secondly:
If I have a
/dev/consoleon a PCI device and I have modprobe set to load 8250_pci or a framebuffer driver when the console is opened you will break the current working behaviour.
No, the pci driver will never get loaded by modprobe 5:1, that's all what this bug is about. It connects to the existing console device when the driver is loaded, and at that moment /dev/console gets working.
Kay
Quoted 2 lines
Yes, log nowhere instead of running in a loop would be much better than loading a 5:1 driver which will never exist as a module.
The loop is detected and terminated.
Quoted 5 lines
Quoted 3 lines
Why is this useful - you now get failing module loads producing no diagnostics and in many case the setup just dying silently.
It's obviously more useful than not to boot up.
What makes you think it will now boot up. The loop is already detected and terminated. What will you do if it doesn't and you get no diagnostics. How will distributions debug those reports in bugzilla.
Quoted 1 line
No, the pci driver will never get loaded by modprobe 5:1,
Why not ? You have no idea how the other millions of Linux users have their module loading rules configured. A change which breaks this behaviour is a regression.
Alan
Quoted 4 lines · Alan Cox
Quoted 2 lines
Yes, log nowhere instead of running in a loop would be much better than loading a 5:1 driver which will never exist as a module.
The loop is detected and terminated.
No. Please back up what you are trying to talk about.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Why is this useful - you now get failing module loads producing no diagnostics and in many case the setup just dying silently.
It's obviously more useful than not to boot up.
What makes you think it will now boot up. The loop is already detected and terminated. What will you do if it doesn't and you get no diagnostics. How will distributions debug those reports in bugzilla.
The boxes of the reporters hang! Read the bug! Please!
Quoted 5 lines
Quoted 1 line
No, the pci driver will never get loaded by modprobe 5:1,
Why not ? You have no idea how the other millions of Linux users have their module loading rules configured. A change which breaks this behaviour is a regression.
There is no cheap way out of the problem, it's a kernel bug, and we will fix it - you may just delay it with your zero arguments.
Kay
Quoted 3 lines
Quoted 1 line
The loop is detected and terminated.
No. Please back up what you are trying to talk about.
Let me introduce you to.. drum roll.. the source code. Its a useful resource, why don't you use it for once.
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
atomic_inc(&kmod_concurrent);
if (atomic_read(&kmod_concurrent) > max_modprobes) {
/* We may be blaming an innocent here, but unlikely */
if (kmod_loop_msg++ < 5)
printk(KERN_ERR
"request_module: runaway loop modprobe
%s\n", module_name);
atomic_dec(&kmod_concurrent);
return -ENOMEM;
}Happy now. Print it out, share it with friends, find someone who can read C if you are stuck.
Quoted 1 line
The boxes of the reporters hang! Read the bug! Please!
They would still hang. As I repeatedly said for the benefit of two people who don't seem to be able to read source code, the loop is detected and terminated. So it already fails the open when it sees it has gotten five layers deep.
Quoted 2 lines
There is no cheap way out of the problem, it's a kernel bug, and we will fix it - you may just delay it with your zero arguments.
Oh I see. Allow me to explain your position in the words of some small children I know
"ME!! ME!! ME!! ME!! ME!!"
I don't care about your obscure corner-case non bug that in fact was a crypto bug combined with a modprobe bug and where the crypto bug is now fixed. I do care about not breaking existing users systems. The fact we do this is why Linux doesn't suck.
Alan
Quoted 20 lines · Alan Cox
Quoted 3 lines
Quoted 1 line
The loop is detected and terminated.
No. Please back up what you are trying to talk about.
Let me introduce you to.. drum roll.. the source code. Its a useful resource, why don't you use it for once.
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT); atomic_inc(&kmod_concurrent); if (atomic_read(&kmod_concurrent) > max_modprobes) { /* We may be blaming an innocent here, but unlikely */ if (kmod_loop_msg++ < 5) printk(KERN_ERR "request_module: runaway loop modprobe %s\n", module_name); atomic_dec(&kmod_concurrent); return -ENOMEM; }
Quoted 2 lines
Happy now. Print it out, share it with friends, find someone who can read C if you are stuck.
It does not work, that's all. Reproduce the bug and look at it for yourself.
It's still a bug, regardless of all the childish stuff you wrap around it.
Quoted 13 lines
Quoted 1 line
The boxes of the reporters hang! Read the bug! Please!
They would still hang. As I repeatedly said for the benefit of two people who don't seem to be able to read source code, the loop is detected and terminated. So it already fails the open when it sees it has gotten five layers deep.
Quoted 2 lines
There is no cheap way out of the problem, it's a kernel bug, and we will fix it - you may just delay it with your zero arguments.
Oh I see. Allow me to explain your position in the words of some small children I know
Quoted 6 lines
"ME!! ME!! ME!! ME!! ME!!"I don't care about your obscure corner-case non bug that in fact was a crypto bug combined with a modprobe bug and where the crypto bug is now fixed. I do care about not breaking existing users systems. The fact we do this is why Linux doesn't suck.
It's not obscure, it's obviously broken. And it currently sucks.
I have no idea why are you repeatedly, with completely wrong arguments trying, to explain "hotplug" stuff to me. I maintain it by the way, and I didn't see you involved here in the last years, so I guess you miss the background to understand the problem.
Kay
Quoted 12 lines
Quoted 12 lines
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT); atomic_inc(&kmod_concurrent); if (atomic_read(&kmod_concurrent) > max_modprobes) { /* We may be blaming an innocent here, but unlikely */ if (kmod_loop_msg++ < 5) printk(KERN_ERR "request_module: runaway loop modprobe %s\n", module_name); atomic_dec(&kmod_concurrent); return -ENOMEM; }
Quoted 4 lines
Quoted 2 lines
Happy now. Print it out, share it with friends, find someone who can read C if you are stuck.
It does not work, that's all.
It works for me.
Quoted 1 line
Reproduce the bug and look at it for yourself.
Well since you've got a reproducer and this code works for me (I've tested it just fine), why don't you go and reproduce the problem then post a fix to that code I quoted instead of all this reordering rubbish. If you fix this code not only won't you risk all the mess from re-ordering initialisations around the kernel but you'll fix non console related looping which you imply is also broken as you claim that code doesn't work for you.
If I deliberately break my module utils I see a sequence of modprobes which then hits kmod_concurrent limit then causes a -ENOMEM back to userspace which then fails the file open. The bug report also shows the printk is displayed so the runaway loop *was* detected and the code paths taken which stopped the loop.
I get open -> modprobe -> open -> modprobe -> open -> modprobe ... -> open fail, then open fail, open fail, open fail, open fail back to the first modprobe exiting.
Your proposal to keep the current recent modprobe parameter strings would shorten the amount of recursion but it wouldn't change the result that I can see. If I open /dev/console early and wrongly from a modprobe then I ultimately get a failing open just as I should do.
Alan
Quoted 12 lines · Alan Cox
Quoted 12 lines
Quoted 12 lines
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT); atomic_inc(&kmod_concurrent); if (atomic_read(&kmod_concurrent) > max_modprobes) { /* We may be blaming an innocent here, but unlikely */ if (kmod_loop_msg++ < 5) printk(KERN_ERR "request_module: runaway loop modprobe %s\n", module_name); atomic_dec(&kmod_concurrent); return -ENOMEM; }
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Happy now. Print it out, share it with friends, find someone who can read C if you are stuck.
It does not work, that's all.
It works for me.
It runs in a loop here, just like the $subject says, and bko#12153 says.
Quoted 10 lines
Quoted 1 line
Reproduce the bug and look at it for yourself.
Well since you've got a reproducer and this code works for me (I've tested it just fine), why don't you go and reproduce the problem then post a fix to that code I quoted instead of all this reordering rubbish. If you fix this code not only won't you risk all the mess from re-ordering initialisations around the kernel but you'll fix non console related looping which you imply is also broken as you claim that code doesn't work for you.
Quoted 5 lines
If I deliberately break my module utils I see a sequence of modprobes which then hits
kmod_concurrentlimit then causes a-ENOMEMback to userspace which then fails the file open. The bug report also shows the printk is displayed so the runaway loop *was* detected and the code paths taken which stopped the loop.
Sure, I can try to find out why the limiter does does not work here.
Quoted 8 lines
I get open -> modprobe -> open -> modprobe -> open -> modprobe ... -> open fail, then open fail, open fail, open fail, open fail back to the first modprobe exiting.
Your proposal to keep the current recent modprobe parameter strings would shorten the amount of recursion but it wouldn't change the result that I can see. If I open
/dev/consoleearly and wrongly from a modprobe then I ultimately get a failing open just as I should do.
No, my proposal would prevent the kernel to call any modprobe for the special built-in device 5:1, it shortens the recursion to zero, which sounds like the right fix. It's really weird to fix the symptoms, instead of the real problem.
The kernel forks a binary with a broken environment. Even the in-kernel-tree cpio generator creates /dev/console, and accessing it from a kernel forked binary makes it crash. The kernel must provide a sane environment for stuff that it calls, I think, that is pretty obvious.
Device 5:1 is a core device, which never makes sense to call modprobe for it. No other later driver will ever register that dev_t, so we should do it before calling out to other random userspace stuff which triggers the kernel to go crazy with its own devices.
My proposal was to connect 5:1 to the kobject map at the same time as we register the whole tty class. We allocate the class, create sysfs entries, run /sbin/modprobe at that time, why shouldn't we just register the dev_t that time too?
It properly prevents the needless userspace "driver searching" for a well known, already created, but not properly registered core device.
It makes the process environment sane, and prevents the root cause of the bug, and does not just limit the damage.
Thanks,
Kay
Let's take a step back, shall we? Fundamentally, what's going on here is that a particular distribution's initrd (Debian's, to be precise) is running into an error in response to a modprobe request for char-major-5-1, and it is attempting to write to the console, which is resulting in another modprobe request.... ad infinitum.
There is a dispute about whether it is looping forever, or whether it should be getting caught by kernel/kmod.c's modprobe recursion detector. Alan has checked the recursion detector and reports that it works just fine; Evgeniy and Kay are claiming that it in fact loops forever, and the recursion detector is not working. I'm going to guess that Alan tested on Fedora, where it did work just fine, and reason why people using a Debian-derived initrd is seeing a recursive loop is because the recursive loop detector works by detecting up to five concurrent calls to modprobe. That is, while the userspace helper process is running, another userspace helper is invoked, and so on, so that there are five userspace helpers piled up on one another, this will trigger the automatic recursion detector. I'm guessing why it isn't working given Debian's initrd setup is that whatever is ultimately opening /dev/console isn't being called until after the helper script has exited.
Given that the general purpose recursion detector is apparently not working at least in this case, Kay has proposed that we special case a kludge wihch prevents the userspace helper be called in the case of 5:1. His argument in favor of doing this is that /dev/console is never a module, so requesting char-major-5-1 will never be helpful, and this error can only happen in early userspace, when the tty subsystem hasn't been initialized yet. Alan claims this could also happen if the appropriate low-level console driver hasn't been loaded, and so perhaps the right thing in response to the request for char-major-5-1 is to load 8250_pci. Here, I think Alan is wrong, and Kay is right. From looking at the source, if there is no low-level console driver loaded, there is no call to request_module(); the only time this can happen is when tty driver hasn't been initialized in early startup.
On the other hand, Alan is right that in general it is the usermode helper and initrd's responsibility not create a recursive dependency. This is in general true, not just for /dev/console. So based on that, it can be argued that the recursion kludge checking for 5:1 should just as much be put in userspace. In addition, the fact that recursion detection isn't working also seems to indicate that initrd in question is also doing something very wrong.
So I would think the best thing to do is to figure out what Debian's initrd is doing that is evading the recursion detection. Fixing that is going to make things much more robust.
Regards,
- Ted
Quoted 45 lines · Theodore Tso
Let's take a step back, shall we? Fundamentally, what's going on here is that a particular distribution's initrd (Debian's, to be precise) is running into an error in response to a modprobe request for char-major-5-1, and it is attempting to write to the console, which is resulting in another modprobe request.... ad infinitum.
There is a dispute about whether it is looping forever, or whether it should be getting caught by kernel/kmod.c's modprobe recursion detector. Alan has checked the recursion detector and reports that it works just fine; Evgeniy and Kay are claiming that it in fact loops forever, and the recursion detector is not working. I'm going to guess that Alan tested on Fedora, where it did work just fine, and reason why people using a Debian-derived initrd is seeing a recursive loop is because the recursive loop detector works by detecting up to five concurrent calls to modprobe. That is, while the userspace helper process is running, another userspace helper is invoked, and so on, so that there are five userspace helpers piled up on one another, this will trigger the automatic recursion detector. I'm guessing why it isn't working given Debian's initrd setup is that whatever is ultimately opening
/dev/consoleisn't being called until after the helper script has exited.Given that the general purpose recursion detector is apparently not working at least in this case, Kay has proposed that we special case a kludge wihch prevents the userspace helper be called in the case of 5:1. His argument in favor of doing this is that
/dev/consoleis never a module, so requesting char-major-5-1 will never be helpful, and this error can only happen in early userspace, when the tty subsystem hasn't been initialized yet. Alan claims this could also happen if the appropriate low-level console driver hasn't been loaded, and so perhaps the right thing in response to the request for char-major-5-1 is to load 8250_pci. Here, I think Alan is wrong, and Kay is right. From looking at the source, if there is no low-level console driver loaded, there is no call torequest_module(); the only time this can happen is when tty driver hasn't been initialized in early startup.On the other hand, Alan is right that in general it is the usermode helper and initrd's responsibility not create a recursive dependency. This is in general true, not just for
/dev/console. So based on that, it can be argued that the recursion kludge checking for 5:1 should just as much be put in userspace. In addition, the fact that recursion detection isn't working also seems to indicate that initrd in question is also doing something very wrong.
Quoted 3 lines
So I would think the best thing to do is to figure out what Debian's initrd is doing that is evading the recursion detection. Fixing that is going to make things much more robust.
I tested it with an initramfs image with /sbin/modprobe being a shell script that writes a few bytes to /dev/console, and does nothing else. It did run for minutes here, until I stopped it.
Sure, if we can make userspace behave nicely, I'm all for doing it. On the other hand, I think it's a good thing to provide a sane environment by the kernel for any "non-initramfs-optimized" helper. Writing to /dev/console is a usual behavior for tools used in initramfs, to be able to debug bootup problems. In many cases it is just glibc's fallback LOG_CONS, if syslog is not available.
Modprobe has syslog code, so it might very well be, that the Debian initramfs isn't doing anything obscure. The current behavior, is very easy to trigger bug, and a pretty hard to debug setup, if you do not add debugging code to the kernel code itself.
That's why I still think it's a good thing, to connect the core tty devices to their dev_t handler internally, before we init all the other drivers and run userspace. It will prevent any further needless searches by the kernel, for a driver for the already created but just not registered tty devices. We will do exactly the same dev_t <->device connection (register_chrdev_region) anyway, directly after loading all the other drivers.
Thanks,
Kay
Quoted 6 lines · Kay Sievers
Sure, if we can make userspace behave nicely, I'm all for doing it. On the other hand, I think it's a good thing to provide a sane environment by the kernel for any "non-initramfs-optimized" helper. Writing to
/dev/consoleis a usual behavior for tools used in initramfs, to be able to debug bootup problems. In many cases it is just glibc's fallbackLOG_CONS, if syslog is not available.
Well, can we agree that (a) there is a generalized modprobe recursion detector already in the kernel, and (b) for some reason, Debian isn't triggering it? That seems like a bug, and while it may not be 100% clear whether the bug is on the userspace side or the kernel side, it would seem that finding and fixing *that* would be a Good Thing, and it could be argued that a specific don't request char-major-5-1 would be papering over this bug (whether it is in Debian's initrd or in the kernel side code). It would be good to make sure we understand what the root causes for while the modprobe recursion detector is apparently not triggering, since it could be that Debian's initrd might cause some other uncaught recursion loop if we don't drive this problem determination to root cause.
Quoted 3 lines
That's why I still think it's a good thing, to connect the core tty devices to their
dev_thandler internally, before we init all the other drivers and run userspace.
Um, how early? (/me searches lkml.org for the original patch). Ah, OK, you want to do it postcore.... There may actually be a problem with that, because it looks like vtconsole_class_init (which is currently run as a postcore initcall) really wants to happen before the tty layer initializes itself. So moving tty into postcore could potentially run into problems, depending on whether vt.c's or tty_io.c's initcalls are run first.
- Ted
Quoted 8 lines · Theodore Tso
Quoted 6 lines · Kay Sievers
Sure, if we can make userspace behave nicely, I'm all for doing it. On the other hand, I think it's a good thing to provide a sane environment by the kernel for any "non-initramfs-optimized" helper. Writing to
/dev/consoleis a usual behavior for tools used in initramfs, to be able to debug bootup problems. In many cases it is just glibc's fallbackLOG_CONS, if syslog is not available.
Quoted 12 lines
Well, can we agree that (a) there is a generalized modprobe recursion detector already in the kernel, and (b) for some reason, Debian isn't triggering it? That seems like a bug, and while it may not be 100% clear whether the bug is on the userspace side or the kernel side, it would seem that finding and fixing *that* would be a Good Thing, and it could be argued that a specific don't request char-major-5-1 would be papering over this bug (whether it is in Debian's initrd or in the kernel side code). It would be good to make sure we understand what the root causes for while the modprobe recursion detector is apparently not triggering, since it could be that Debian's initrd might cause some other uncaught recursion loop if we don't drive this problem determination to root cause.
Right, it would be good to know for sure what's going on.
In my test script it was just a simple access to /dev/console, so it might just be that modprobe wants to log something on Debian. At least that would match the behavior I've seen here.
And we really rely on these tools to be able to print debug messages sometimes to find other bugs (at least at the time it's theoretically possible to log). And I don't see how modprobe could find out, that it is not allowed to access /dev/console.
As an ideal solution, I would like to have /dev/console working before _any_ userspace is called, and it would put all the stuff that is written to it the kernel "dmesg buffer" as long as the console isn't working, just to be able to see what's going on, if needed. As the second choice, it would return -ENODEV. The current looping is definitely not what we want. :)
Quoted 11 lines
Quoted 3 lines
That's why I still think it's a good thing, to connect the core tty devices to their
dev_thandler internally, before we init all the other drivers and run userspace.Um, how early? (/me searches lkml.org for the original patch). Ah, OK, you want to do it postcore.... There may actually be a problem with that, because it looks like
vtconsole_class_init(which is currently run as a postcore initcall) really wants to happen before the tty layer initializes itself. So moving tty into postcore could potentially run into problems, depending on whether vt.c's or tty_io.c's initcalls are run first.
Sure, we might need to change that, if it is a problem. It was mainly to find out what was going on, because people thought that some serial driver is involved in the loop, which I didn't believe.
To be safer, maybe we just want to move the cdev_add(), register_chrdev_region() call, which should prevent the "userspace driver search".
Thanks,
Kay
Quoted 3 lines
apparently not triggering, since it could be that Debian's initrd might cause some other uncaught recursion loop if we don't drive this problem determination to root cause.
Agreed - and there are all sorts of obscure and wonderful other ways to trip this up which need the detector (AF_UNIX modular and doing a syslog for example).
Quoted 11 lines
Quoted 3 lines
That's why I still think it's a good thing, to connect the core tty devices to their
dev_thandler internally, before we init all the other drivers and run userspace.Um, how early? (/me searches lkml.org for the original patch). Ah, OK, you want to do it postcore.... There may actually be a problem with that, because it looks like
vtconsole_class_init(which is currently run as a postcore initcall) really wants to happen before the tty layer initializes itself. So moving tty into postcore could potentially run into problems, depending on whether vt.c's or tty_io.c's initcalls are run first.
Its playing with fire and doing so to paper over a completely different problem. The recursion detector is generic and should be sufficient. If it isn't then it needs improving to be generic, sufficient and working.
Quoted 7 lines · Herbert Xu
Having said that I think this patch should remove this particular trigger. Unfortunately I couldn't find a more succinct way of expressing this relationship: if ALGAPI is built-in because it's selected by an algorithm, and
CRYPTO_MANAGERis enabled then we requireCRYPTO_MANAGERto be built-in as well.Evgeniy, please let me know whether this fixes the problem.
Holy shit... This looks 'excellent' :)
I will try it tomorrow and report back the results.
Signature · 1 line
Evgeniy Polyakov
Quoted 7 lines · Herbert Xu
Having said that I think this patch should remove this particular trigger. Unfortunately I couldn't find a more succinct way of expressing this relationship: if ALGAPI is built-in because it's selected by an algorithm, and
CRYPTO_MANAGERis enabled then we requireCRYPTO_MANAGERto be built-in as well.Evgeniy, please let me know whether this fixes the problem.
Your patch does not apply cleanly to the latest git and missed rng dependency to rng2.
Attached patch fixes problem with module loading for me.
crypto/Kconfig +32 -4
@@ -31,35 +31,63 @@ config CRYPTO_FIPS config CRYPTO_ALGAPI tristate + select CRYPTO_ALGAPI2 help This option provides the API for cryptographic algorithms. +config CRYPTO_ALGAPI2 + tristate + config CRYPTO_AEAD tristate + select CRYPTO_AEAD2 select CRYPTO_ALGAPI +config CRYPTO_AEAD2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_BLKCIPHER tristate + select CRYPTO_BLKCIPHER2 select CRYPTO_ALGAPI - select CRYPTO_RNG + +config CRYPTO_BLKCIPHER2 + tristate + select CRYPTO_ALGAPI2 + select CRYPTO_RNG2 config CRYPTO_HASH tristate + select CRYPTO_HASH2 select CRYPTO_ALGAPI +config CRYPTO_HASH2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_RNG tristate + select CRYPTO_RNG2 select CRYPTO_ALGAPI +config CRYPTO_RNG2 + tristate + select CRYPTO_ALGAPI2 + config CRYPTO_MANAGER tristate "Cryptographic algorithm manager" - select CRYPTO_AEAD - select CRYPTO_HASH - select CRYPTO_BLKCIPHER + select CRYPTO_MANAGER2 help Create default cryptographic template instantiations such as cbc(aes). +config CRYPTO_MANAGER2 + def_tristate CRYPTO_MANAGER || (CRYPTO_MANAGER!=n && CRYPTO_ALGAPI=y) + select CRYPTO_AEAD2 + select CRYPTO_HASH2 + select CRYPTO_BLKCIPHER2 + config CRYPTO_GF128MUL tristate "GF(2^128) multiplication functions (EXPERIMENTAL)" depends on EXPERIMENTAL
crypto/Makefile +9 -9
@@ -9,24 +9,24 @@ obj-$(CONFIG_CRYPTO_FIPS) += fips.o crypto_algapi-$(CONFIG_PROC_FS) += proc.o crypto_algapi-objs := algapi.o scatterwalk.o $(crypto_algapi-y) -obj-$(CONFIG_CRYPTO_ALGAPI) += crypto_algapi.o +obj-$(CONFIG_CRYPTO_ALGAPI2) += crypto_algapi.o -obj-$(CONFIG_CRYPTO_AEAD) += aead.o +obj-$(CONFIG_CRYPTO_AEAD2) += aead.o crypto_blkcipher-objs := ablkcipher.o crypto_blkcipher-objs += blkcipher.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += crypto_blkcipher.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += chainiv.o -obj-$(CONFIG_CRYPTO_BLKCIPHER) += eseqiv.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += crypto_blkcipher.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += chainiv.o +obj-$(CONFIG_CRYPTO_BLKCIPHER2) += eseqiv.o obj-$(CONFIG_CRYPTO_SEQIV) += seqiv.o crypto_hash-objs := hash.o crypto_hash-objs += ahash.o -obj-$(CONFIG_CRYPTO_HASH) += crypto_hash.o +obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o cryptomgr-objs := algboss.o testmgr.o -obj-$(CONFIG_CRYPTO_MANAGER) += cryptomgr.o +obj-$(CONFIG_CRYPTO_MANAGER2) += cryptomgr.o obj-$(CONFIG_CRYPTO_HMAC) += hmac.o obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
@@ -73,8 +73,8 @@ obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o obj-$(CONFIG_CRYPTO_LZO) += lzo.o -obj-$(CONFIG_CRYPTO_RNG) += rng.o -obj-$(CONFIG_CRYPTO_RNG) += krng.o +obj-$(CONFIG_CRYPTO_RNG2) += rng.o +obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
Signature · 1 line
Evgeniy Polyakov
Herbert Xu
maintainerQuoted 3 lines · Evgeniy Polyakov
Your patch does not apply cleanly to the latest git and missed rng dependency to rng2.
Right it was against cryptodev-2.6 actually. Thanks for fixing it up and confirming. I'll submit this to Linus.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtHi.
Quoted 8 lines · Kay Sievers
I don't know if it may have any bad side-effects. It moves the tty registration earlier, before we do pci, framebuffer, video, acpi registration.
It boots fine here with and without initramfs.
Maybe it makes the "dead"
/dev/consolein your initramfs working, then we at least know the problem.
Your patch fixes boot process in my case.
Signature · 1 line
Evgeniy Polyakov
Quoted 5 lines · On Sat, 6 Dec 2008 00:12:23 +0300 Evgeniy Polyakov <[email protected]> wrote:
Quoted 4 lines · Alan Cox
Quoted 4 lines
I can not run bisect, since reboot requires vnc and I'm far from fast channel. Build of the fresh tree with existing config takes almost one hour, but it should not be a major problem.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I can do bisection after the weekend, but can test some changes before machine froze with unsuccessful patch.
I really have no idea what you are seeing so short of a bisect I've nothing to suggest.
But if things would be in userspace, then it should be fired long ago with .27 kernel, no?
I have no idea. A bisection will hopefully provide answers