2.6.15-mm4 failure on power5

2.6.15-mm4 failure on power5

[Serge E. Hallyn]

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

On my power5 partition, 2.6.15-mm4 hangs on boot with the following
console output.  2.6.15-mm3 booted fine.  .config attached.

boot: quicktest
Please wait, loading kernel...
   Elf64 kernel loaded...
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: ro console=hvc0 root=/dev/sda6 smt-enabled=1 
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000002223000
  alloc_top    : 0000000008000000
  alloc_top_hi : 0000000088000000
  rmo_top      : 0000000008000000
  ram_top      : 0000000088000000
Looking for displays
instantiating rtas at 0x00000000077d7000 ... done
0000000000000000 : boot cpu     0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002424000 -> 0x0000000002424f36
Device tree struct  0x0000000002425000 -> 0x000000000242c000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12

thanks,
-serge

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

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15-mm3
# Sun Jan 15 18:03:01 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_CRASH_DUMP is not set
# CONFIG_GENERIC_TBSYNC is not set

#
# Processor support
#
# CONFIG_POWER4_ONLY is not set
CONFIG_POWER3=y
CONFIG_POWER4=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_SMP=y
CONFIG_NR_CPUS=128

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
CONFIG_SERIAL_PCI=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
# CONFIG_BLK_DEV_IO_TRACE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_PPC_ISERIES is not set
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
CONFIG_PPC_PSERIES=y
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
# CONFIG_PPC_CELL is not set
CONFIG_XICS=y
# CONFIG_U3_DART is not set
CONFIG_MPIC=y
CONFIG_PPC_RTAS=y
CONFIG_RTAS_ERROR_LOGGING=y
# CONFIG_RTAS_PROC is not set
# CONFIG_MMIO_NVRAM is not set
CONFIG_IBMVIO=y
CONFIG_IBMEBUS=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set

#
# Kernel options
#
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_FORCE_MAX_ZONEORDER=13
# CONFIG_IOMMU_VMERGE is not set
CONFIG_HOTPLUG_CPU=y
# CONFIG_KEXEC is not set
# CONFIG_IRQ_ALL_CPUS is not set
CONFIG_PPC_SPLPAR=y
# CONFIG_HMT is not set
CONFIG_EEH=y
CONFIG_LPARCFG=y
CONFIG_NUMA=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
# CONFIG_PPC_64K_PAGES is not set
CONFIG_SCHED_SMT=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y

#
# Bus options
#
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PPC_I8259=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_HOTPLUG_PCI_RPA=y
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
CONFIG_KERNEL_START=0xc000000000000000

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_ROUTE_FWMARK is not set
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
CONFIG_IP_NF_QUEUE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=m

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

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
CONFIG_SCTP_HMAC_NONE=y
# CONFIG_SCTP_HMAC_SHA1 is not set
# CONFIG_SCTP_HMAC_MD5 is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=y
CONFIG_LLC2=m
CONFIG_IPX=m
CONFIG_IPX_INTERN=y
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set

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

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=123456
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

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

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_SL82C105=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_IDEDMA_FORCED=y
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_SVWKS is not set
CONFIG_BLK_DEV_SIIMAGE=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

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

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

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SAS_CLASS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_IPS=y
CONFIG_SCSI_IBMVSCSI=y
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
CONFIG_SCSI_DEBUG=m

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID5=m
# CONFIG_MD_RAID6 is not set
CONFIG_MD_MULTIPATH=m
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
# CONFIG_DM_MULTIPATH is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#
# CONFIG_WINDFARM is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_OAKNET is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBMVETH=y
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=m
# CONFIG_BNX2 is not set
# CONFIG_MV643XX_ETH is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_S2IO=m
CONFIG_S2IO_NAPI=y

#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMOL=m
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_TSDEV=m
CONFIG_INPUT_TSDEV_SCREEN_X=240
CONFIG_INPUT_TSDEV_SCREEN_Y=320
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_UINPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_ICOM=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_CONSOLE=y
CONFIG_HVCS=m

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_WATCHDOG_RTAS is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=4096
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MACMODES=y
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_OF=y
# CONFIG_FB_CT65550 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3TRIO is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

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

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# EDAC - error detection and reporting (RAS)
#

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# 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=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ASFS_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=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Library routines
#
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_DEBUG_SYNCHRO_TEST is not set
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUGGER=y
# CONFIG_KGDB is not set
CONFIG_XMON=y
# CONFIG_XMON_DEFAULT is not set
CONFIG_IRQSTACKS=y
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
# CONFIG_PPC_EARLY_DEBUG_G5 is not set
# CONFIG_PPC_EARLY_DEBUG_RTAS is not set
# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
CONFIG_CRYPTO_TEST=m

#
# Hardware crypto devices
#

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

"Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> On my power5 partition, 2.6.15-mm4 hangs on boot with the following
>  console output.  2.6.15-mm3 booted fine.  .config attached.
> 
>  boot: quicktest
>  Please wait, loading kernel...
>     Elf64 kernel loaded...
>  OF stdout device is: /vdevice/vty@30000000
>  Hypertas detected, assuming LPAR !
>  command line: ro console=hvc0 root=/dev/sda6 smt-enabled=1 
>  memory layout at init:
>    memory_limit : 0000000000000000 (16 MB aligned)
>    alloc_bottom : 0000000002223000
>    alloc_top    : 0000000008000000
>    alloc_top_hi : 0000000088000000
>    rmo_top      : 0000000008000000
>    ram_top      : 0000000088000000
>  Looking for displays
>  instantiating rtas at 0x00000000077d7000 ... done
>  0000000000000000 : boot cpu     0000000000000000
>  0000000000000002 : starting cpu hw idx 0000000000000002... done
>  0000000000000004 : starting cpu hw idx 0000000000000004... done
>  0000000000000006 : starting cpu hw idx 0000000000000006... done
>  copying OF device tree ...
>  Building dt strings...
>  Building dt structure...
>  Device tree strings 0x0000000002424000 -> 0x0000000002424f36
>  Device tree struct  0x0000000002425000 -> 0x000000000242c000
>  Calling quiesce ...
>  returning from prom_init
>  Page orders: linear mapping = 24, others = 12

It might be worth reverting the changes to arch/powerpc/mm/hash_utils_64.c,
see if that unbreaks it.

-		base = lmb.memory.region[i].base + KERNELBASE;
+		base = (unsigned long)__va(lmb.memory.region[i].base);

The nice comment in page.h:

 * KERNELBASE is the virtual address of the start of the kernel, it's often
 * the same as PAGE_OFFSET, but _might not be_.
 *
 * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
 *
 * To get a physical address from a virtual one you subtract PAGE_OFFSET,
 * _not_ KERNELBASE.

Tells us that was not an equivalent transformation.

Re: 2.6.15-mm4 failure on power5

[Michael Ellerman]

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

On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > On my power5 partition, 2.6.15-mm4 hangs on boot
>
> It might be worth reverting the changes to arch/powerpc/mm/hash_utils_64.c,
> see if that unbreaks it.
>
> -		base = lmb.memory.region[i].base + KERNELBASE;
> +		base = (unsigned long)__va(lmb.memory.region[i].base);

You can try it, but if that fixes the problem I'll buy a sombrero and then eat 
it.

> The nice comment in page.h:
>
>  * KERNELBASE is the virtual address of the start of the kernel, it's often
>  * the same as PAGE_OFFSET, but _might not be_.
>  *
>  * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
>  *
>  * To get a physical address from a virtual one you subtract PAGE_OFFSET,
>  * _not_ KERNELBASE.
>
> Tells us that was not an equivalent transformation.

True, not equivalent in all cases, but correct. For non-kdump kernels (which I 
assume this is) KERNELBASE == PAGE_OFFSET, and for a kdump kernel that code 
wants to use PAGE_OFFSET, not KERNELBASE.

Try enabling early debugging (see arch/powerpc/kernel/setup_64.c) and then 
turning on DEBUG in hash_utils_64.c, setup_64.c etc.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-mm4 failure on power5

[Serge E. Hallyn]

Quoting Michael Ellerman (michael@ellerman.id.au):
> On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > On my power5 partition, 2.6.15-mm4 hangs on boot
> >
> > It might be worth reverting the changes to arch/powerpc/mm/hash_utils_64.c,
> > see if that unbreaks it.
> >
> > -		base = lmb.memory.region[i].base + KERNELBASE;
> > +		base = (unsigned long)__va(lmb.memory.region[i].base);
> 
> You can try it, but if that fixes the problem I'll buy a sombrero and then eat 
> it.

Sounds unpleasant, but no need - that didn't fix it.

> > The nice comment in page.h:
> >
> >  * KERNELBASE is the virtual address of the start of the kernel, it's often
> >  * the same as PAGE_OFFSET, but _might not be_.
> >  *
> >  * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
> >  *
> >  * To get a physical address from a virtual one you subtract PAGE_OFFSET,
> >  * _not_ KERNELBASE.
> >
> > Tells us that was not an equivalent transformation.
> 
> True, not equivalent in all cases, but correct. For non-kdump kernels (which I 
> assume this is) KERNELBASE == PAGE_OFFSET, and for a kdump kernel that code 
> wants to use PAGE_OFFSET, not KERNELBASE.
> 
> Try enabling early debugging (see arch/powerpc/kernel/setup_64.c) and then 
> turning on DEBUG in hash_utils_64.c, setup_64.c etc.

That gives me the following output:

boot: quicktest
Please wait, loading kernel...
   Elf64 kernel loaded...
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: ro console=hvc0 root=/dev/sda6 smt-enabled=1 
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000002223000
  alloc_top    : 0000000008000000
  alloc_top_hi : 0000000088000000
  rmo_top      : 0000000008000000
  ram_top      : 0000000088000000
Looking for displays
instantiating rtas at 0x00000000077d7000 ... done
0000000000000000 : boot cpu     0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002424000 -> 0x0000000002424f36
Device tree struct  0x0000000002425000 -> 0x000000000242c000
Calling quiesce ...
returning from prom_init
 -> early_setup()
Probing machine type for platform 101...
Found, Initializing memory management...
 -> htab_initialize()
creating mapping for region: c000000000000000 : 88000000
 <- htab_initialize()
 <- early_setup()
 -> setup_system()
 -> initialize_cache_info()
 <- initialize_cache_info()
Page orders: linear mapping = 24, others = 12
 -> smp_release_cpus()
 <- smp_release_cpus()
 <- setup_system()

So setup_system() at least finishes, though I don't see the
printk's at the bottom of that function.

thanks,
-serge

Re: 2.6.15-mm4 failure on power5

[Dave C Boutcher]

On Mon, Jan 16, 2006 at 09:37:48AM -0600, Serge E. Hallyn wrote:
> Quoting Michael Ellerman (michael@ellerman.id.au):
> > On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > On my power5 partition, 2.6.15-mm4 hangs on boot
> 
> boot: quicktest
> Please wait, loading kernel...

...

> Page orders: linear mapping = 24, others = 12
>  -> smp_release_cpus()
>  <- smp_release_cpus()
>  <- setup_system()
> 
> So setup_system() at least finishes, though I don't see the
> printk's at the bottom of that function.

2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch

If I revert just that patch, mm4 boots fine.  Its really not obvious to
me at all why that patch is breaking things though...

-- 
Dave Boutcher

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

Dave C Boutcher <sleddog@us.ibm.com> wrote:
>
> On Mon, Jan 16, 2006 at 09:37:48AM -0600, Serge E. Hallyn wrote:
> > Quoting Michael Ellerman (michael@ellerman.id.au):
> > > On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> > > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > > On my power5 partition, 2.6.15-mm4 hangs on boot
> > 
> > boot: quicktest
> > Please wait, loading kernel...
> 
> ...
> 
> > Page orders: linear mapping = 24, others = 12
> >  -> smp_release_cpus()
> >  <- smp_release_cpus()
> >  <- setup_system()
> > 
> > So setup_system() at least finishes, though I don't see the
> > printk's at the bottom of that function.
> 
> 2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
> following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch

Thanks for doing that - I know it's a lot of work, but boy it helps.

<mutters something unprintable about mutex patches and work prioritisation>

> If I revert just that patch, mm4 boots fine.  Its really not obvious to
> me at all why that patch is breaking things though...
> 

Yes, that is strange.  I do recall that if something accidentally enables
interrupts too early in boot, ppc64 machines tend to go comatose.  But if
we'd been running that code under local_irq_disable(), down() would have
spat a warning.

Drat, it seems I don't have CPU hotplug in my ppc64 config.

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > If I revert just that patch, mm4 boots fine.  Its really not obvious to
> > me at all why that patch is breaking things though...
> 
> Yes, that is strange.  I do recall that if something accidentally 
> enables interrupts too early in boot, ppc64 machines tend to go 
> comatose.  But if we'd been running that code under 
> local_irq_disable(), down() would have spat a warning.

perhaps it was just luck it worked so far, and the bug could have had 
worse incarnations that the current clear hang if a certain generic 
codepath is touched in a perfectly valid way. Does CONFIG_DEBUG_MUTEXES 
(or any of the other debugging options) make any noise?

	Ingo

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > If I revert just that patch, mm4 boots fine.  Its really not obvious to
> > > me at all why that patch is breaking things though...
> > 
> > Yes, that is strange.  I do recall that if something accidentally 
> > enables interrupts too early in boot, ppc64 machines tend to go 
> > comatose.  But if we'd been running that code under 
> > local_irq_disable(), down() would have spat a warning.
> 
> perhaps it was just luck it worked so far, and the bug could have had 
> worse incarnations that the current clear hang if a certain generic 
> codepath is touched in a perfectly valid way. Does CONFIG_DEBUG_MUTEXES 
> (or any of the other debugging options) make any noise?
> 

The bug happens on the G5 too.  There's nothing useful on the screen,
nothing on netconsole.  Could the people whose machines have a fscking
serial port please try CONFIG_DEBUG_MUTEXES?

Re: 2.6.15-mm4 failure on power5

[Dave C Boutcher]

On Tue, Jan 17, 2006 at 09:17:49AM +0100, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > If I revert just that patch, mm4 boots fine.  Its really not obvious to
> > > me at all why that patch is breaking things though...
> > 
> > Yes, that is strange.  I do recall that if something accidentally 
> > enables interrupts too early in boot, ppc64 machines tend to go 
> > comatose.  But if we'd been running that code under 
> > local_irq_disable(), down() would have spat a warning.
> 
> perhaps it was just luck it worked so far, and the bug could have had 
> worse incarnations that the current clear hang if a certain generic 
> codepath is touched in a perfectly valid way. Does CONFIG_DEBUG_MUTEXES 
> (or any of the other debugging options) make any noise?

Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
along...so no noise.  My console output is a little different that
Serge's, so I think this is timing related.  Also note that I'm dying in
the timer interrupt...

Please wait, loading kernel...
   Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02600000, size: 1212 Kbytes
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda3 selinux=0 elevator=cfq
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 000000000272f000
  alloc_top    : 0000000008000000
  alloc_top_hi : 0000000100000000
  rmo_top      : 0000000008000000
  ram_top      : 0000000100000000
Looking for displays
found display   : /pci@800000020000002/pci@2,6/pci@1/display@0, opening
... doneinstantiating rtas at 0x0000000007734000 ... done
0000000000000000 : boot cpu     0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002a30000 -> 0x0000000002a313f5
Device tree struct  0x0000000002a32000 -> 0x0000000002a42000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12
Found initrd at 0xc000000002600000:0xc00000000272f000
cpu 0x0: Vector: 300 (Data Access) at [c000000000577520]
    pc: c000000000021064: .timer_interrupt+0xf4/0x440
    lr: c000000000021020: .timer_interrupt+0xb0/0x440
    sp: c0000000005777a0
   msr: 8000000000001032
   dar: 10
 dsisr: 40000000
  current = 0xc0000000005c1150
  paca    = 0xc0000000005c1d00
    pid   = 0, comm = swapper
enter ? for help
0:mon>


-- 
Dave Boutcher

Re: 2.6.15-mm4 failure on power5

[Dave C Boutcher]

On Tue, Jan 17, 2006 at 10:52:44AM -0600, Dave C Boutcher wrote:
> Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
> along...so no noise.  My console output is a little different that
> Serge's, so I think this is timing related.  Also note that I'm dying in
> the timer interrupt...

duh... here's the backtrace
0:mon> t
[c000000000577890] c0000000000034b4 decrementer_common+0xb4/0x100
--- Exception: 901 (Decrementer) at c0000000004627ec
.__mutex_lock_interruptible_slowpath+0x3bc/0x4c4
[c000000000577c60] c000000000075064 .__lock_cpu_hotplug+0x44/0xa8
[c000000000577ce0] c000000000075600 .register_cpu_notifier+0x24/0x68
[c000000000577d70] c00000000052cd7c .do_init_bootmem+0x68c/0xab0
[c000000000577e50] c000000000522c84 .setup_arch+0x21c/0x2c0
[c000000000577ef0] c00000000051a538 .start_kernel+0x40/0x280
[c000000000577f90] c000000000008574 .hmt_init+0x0/0x8c


-- 
Dave Boutcher

Re: 2.6.15-mm4 failure on power5

[Nathan Lynch]

Dave C Boutcher wrote:
> On Tue, Jan 17, 2006 at 10:52:44AM -0600, Dave C Boutcher wrote:
> > Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
> > along...so no noise.  My console output is a little different that
> > Serge's, so I think this is timing related.  Also note that I'm dying in
> > the timer interrupt...
> 
> duh... here's the backtrace
> 0:mon> t
> [c000000000577890] c0000000000034b4 decrementer_common+0xb4/0x100
> --- Exception: 901 (Decrementer) at c0000000004627ec
> .__mutex_lock_interruptible_slowpath+0x3bc/0x4c4
> [c000000000577c60] c000000000075064 .__lock_cpu_hotplug+0x44/0xa8
> [c000000000577ce0] c000000000075600 .register_cpu_notifier+0x24/0x68
> [c000000000577d70] c00000000052cd7c .do_init_bootmem+0x68c/0xab0
> [c000000000577e50] c000000000522c84 .setup_arch+0x21c/0x2c0
> [c000000000577ef0] c00000000051a538 .start_kernel+0x40/0x280
> [c000000000577f90] c000000000008574 .hmt_init+0x0/0x8c

The mutex debug code (debug_spin_unlock in kernel/mutex-debug.h) is
doing a local_irq_enable way before we're ready.

BTW: I couldn't build powerpc without mutex debugging until I changed
the SYNC_ON_SMP in include/asm-powerpc/mutex.h:__mutex_fastpath_unlock
to ISYNC_ON_SMP.

With that change, I was able to boot semi-successfully with mutex
debugging off -- the system got hung up when udev started, apparently
(or maybe I was too impatient).

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Nathan Lynch <ntl@pobox.com> wrote:

> Dave C Boutcher wrote:
> > On Tue, Jan 17, 2006 at 10:52:44AM -0600, Dave C Boutcher wrote:
> > > Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
> > > along...so no noise.  My console output is a little different that
> > > Serge's, so I think this is timing related.  Also note that I'm dying in
> > > the timer interrupt...
> > 
> > duh... here's the backtrace
> > 0:mon> t
> > [c000000000577890] c0000000000034b4 decrementer_common+0xb4/0x100
> > --- Exception: 901 (Decrementer) at c0000000004627ec
> > .__mutex_lock_interruptible_slowpath+0x3bc/0x4c4
> > [c000000000577c60] c000000000075064 .__lock_cpu_hotplug+0x44/0xa8
> > [c000000000577ce0] c000000000075600 .register_cpu_notifier+0x24/0x68
> > [c000000000577d70] c00000000052cd7c .do_init_bootmem+0x68c/0xab0
> > [c000000000577e50] c000000000522c84 .setup_arch+0x21c/0x2c0
> > [c000000000577ef0] c00000000051a538 .start_kernel+0x40/0x280
> > [c000000000577f90] c000000000008574 .hmt_init+0x0/0x8c
> 
> The mutex debug code (debug_spin_unlock in kernel/mutex-debug.h) is 
> doing a local_irq_enable way before we're ready.
> 
> BTW: I couldn't build powerpc without mutex debugging until I changed 
> the SYNC_ON_SMP in include/asm-powerpc/mutex.h:__mutex_fastpath_unlock 
> to ISYNC_ON_SMP.
> 
> With that change, I was able to boot semi-successfully with mutex 
> debugging off -- the system got hung up when udev started, apparently 
> (or maybe I was too impatient).

ugh! Does the patch below get you a working system with DEBUG_MUTEXES=n?

	Ingo

--

revert the ppc64 mutex fastpath assembly optimizations for now.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----
 include/asm-powerpc/mutex.h |   85 ++------------------------------------------
 1 files changed, 5 insertions(+), 80 deletions(-)

Index: linux/include/asm-powerpc/mutex.h
===================================================================
--- linux.orig/include/asm-powerpc/mutex.h
+++ linux/include/asm-powerpc/mutex.h
@@ -1,84 +1,9 @@
 /*
- * include/asm-powerpc/mutex.h
+ * Pull in the generic implementation for the mutex fastpath.
  *
- * PowerPC optimized mutex locking primitives
- *
- * Please look into asm-generic/mutex-xchg.h for a formal definition.
- * Copyright (C) 2006 Joel Schopp <jschopp@austin.ibm.com>, IBM
+ * TODO: implement optimized primitives instead, or leave the generic
+ * implementation in place, or pick the atomic_xchg() based generic
+ * implementation. (see asm-generic/mutex-xchg.h for details)
  */
-#ifndef _ASM_MUTEX_H
-#define _ASM_MUTEX_H
-#define __mutex_fastpath_lock(count, fail_fn)\
-do{					\
-	int tmp;			\
-	__asm__ __volatile__(		\
-"1:	lwarx		%0,0,%1\n"	\
-"	addic		%0,%0,-1\n"	\
-"	stwcx.		%0,0,%1\n"	\
-"	bne-		1b\n"		\
-	ISYNC_ON_SMP			\
-	: "=&r" (tmp)			\
-	: "r" (&(count)->counter)	\
-	: "cr0", "memory");		\
-	if (unlikely(tmp < 0))		\
-		fail_fn(count);		\
-} while (0)
-
-#define __mutex_fastpath_unlock(count, fail_fn)\
-do{					\
-	int tmp;			\
-	__asm__ __volatile__(SYNC_ON_SMP\
-"1:	lwarx		%0,0,%1\n"	\
-"	addic		%0,%0,1\n"	\
-"	stwcx.		%0,0,%1\n"	\
-"	bne-		1b\n"		\
-	: "=&r" (tmp)			\
-	: "r" (&(count)->counter)	\
-	: "cr0", "memory");		\
-	if (unlikely(tmp <= 0))		\
-		fail_fn(count);		\
-} while (0)
-
-
-static inline int
-__mutex_fastpath_trylock(atomic_t* count, int (*fail_fn)(atomic_t*))
-{
-	int tmp;
-	__asm__ __volatile__(
-"1:	lwarx		%0,0,%1\n"
-"	cmpwi		0,%0,1\n"
-"	bne-		2f\n"
-"	addic		%0,%0,-1\n"
-"	stwcx.		%0,0,%1\n"
-"	bne-		1b\n"
-"	isync\n"
-"2:"
-	: "=&r" (tmp)
-	: "r" (&(count)->counter)
-	: "cr0", "memory");
-
-	return (int)tmp;
-
-}
-
-#define __mutex_slowpath_needs_to_unlock()		1
 
-static inline int
-__mutex_fastpath_lock_retval(atomic_t* count, int (*fail_fn)(atomic_t *))
-{
-	int tmp;
-	__asm__ __volatile__(
-"1:	lwarx		%0,0,%1\n"
-"	addic		%0,%0,-1\n"
-"	stwcx.		%0,0,%1\n"
-"	bne-		1b\n"
-"	isync		\n"
-	: "=&r" (tmp)
-	: "r" (&(count)->counter)
-	: "cr0", "memory");
-	if (unlikely(tmp < 0))
-		return fail_fn(count);
-	else
-		return 0;
-}
-#endif
+#include <asm-generic/mutex-dec.h>

Re: 2.6.15-mm4 failure on power5

[Nathan Lynch]

Ingo Molnar wrote:
> 
> * Nathan Lynch <ntl@pobox.com> wrote:
> 
> > Dave C Boutcher wrote:
> > > On Tue, Jan 17, 2006 at 10:52:44AM -0600, Dave C Boutcher wrote:
> > > > Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
> > > > along...so no noise.  My console output is a little different that
> > > > Serge's, so I think this is timing related.  Also note that I'm dying in
> > > > the timer interrupt...
> > > 
> > > duh... here's the backtrace
> > > 0:mon> t
> > > [c000000000577890] c0000000000034b4 decrementer_common+0xb4/0x100
> > > --- Exception: 901 (Decrementer) at c0000000004627ec
> > > .__mutex_lock_interruptible_slowpath+0x3bc/0x4c4
> > > [c000000000577c60] c000000000075064 .__lock_cpu_hotplug+0x44/0xa8
> > > [c000000000577ce0] c000000000075600 .register_cpu_notifier+0x24/0x68
> > > [c000000000577d70] c00000000052cd7c .do_init_bootmem+0x68c/0xab0
> > > [c000000000577e50] c000000000522c84 .setup_arch+0x21c/0x2c0
> > > [c000000000577ef0] c00000000051a538 .start_kernel+0x40/0x280
> > > [c000000000577f90] c000000000008574 .hmt_init+0x0/0x8c
> > 
> > The mutex debug code (debug_spin_unlock in kernel/mutex-debug.h) is 
> > doing a local_irq_enable way before we're ready.
> > 
> > BTW: I couldn't build powerpc without mutex debugging until I changed 
> > the SYNC_ON_SMP in include/asm-powerpc/mutex.h:__mutex_fastpath_unlock 
> > to ISYNC_ON_SMP.
> > 
> > With that change, I was able to boot semi-successfully with mutex 
> > debugging off -- the system got hung up when udev started, apparently 
> > (or maybe I was too impatient).
> 
> ugh! Does the patch below get you a working system with DEBUG_MUTEXES=n?


Yes, this gets me to a login prompt, thanks.

Re: 2.6.15-mm4 failure on power5

[Nathan Lynch]

Nathan Lynch wrote:
> Dave C Boutcher wrote:
> > On Tue, Jan 17, 2006 at 10:52:44AM -0600, Dave C Boutcher wrote:
> > > Well, it turns out that I've been running with CONFIG_DEBUG_MUTEXES all
> > > along...so no noise.  My console output is a little different that
> > > Serge's, so I think this is timing related.  Also note that I'm dying in
> > > the timer interrupt...
> > 
> > duh... here's the backtrace
> > 0:mon> t
> > [c000000000577890] c0000000000034b4 decrementer_common+0xb4/0x100
> > --- Exception: 901 (Decrementer) at c0000000004627ec
> > .__mutex_lock_interruptible_slowpath+0x3bc/0x4c4
> > [c000000000577c60] c000000000075064 .__lock_cpu_hotplug+0x44/0xa8
> > [c000000000577ce0] c000000000075600 .register_cpu_notifier+0x24/0x68
> > [c000000000577d70] c00000000052cd7c .do_init_bootmem+0x68c/0xab0
> > [c000000000577e50] c000000000522c84 .setup_arch+0x21c/0x2c0
> > [c000000000577ef0] c00000000051a538 .start_kernel+0x40/0x280
> > [c000000000577f90] c000000000008574 .hmt_init+0x0/0x8c
> 
> The mutex debug code (debug_spin_unlock in kernel/mutex-debug.h) is
> doing a local_irq_enable way before we're ready.

Looks like not only the powerpc setup_arch code could trigger this --
rcu_init, init_timers, and sched_init all do register_cpu_notifier
(and hence mutex_lock, therefore potentially enabling interrupts too
early in the mutex debug case) before the initial local_irq_enable in
start_kernel.

Re: 2.6.15-mm4 failure on power5

[Serge E. Hallyn]

Quoting Dave C Boutcher (sleddog@us.ibm.com):
> On Mon, Jan 16, 2006 at 09:37:48AM -0600, Serge E. Hallyn wrote:
> > Quoting Michael Ellerman (michael@ellerman.id.au):
> > > On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> > > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > > On my power5 partition, 2.6.15-mm4 hangs on boot
> > 
> > boot: quicktest
> > Please wait, loading kernel...
> 
> ...
> 
> > Page orders: linear mapping = 24, others = 12
> >  -> smp_release_cpus()
> >  <- smp_release_cpus()
> >  <- setup_system()
> > 
> > So setup_system() at least finishes, though I don't see the
> > printk's at the bottom of that function.
> 
> 2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
> following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch
> 
> If I revert just that patch, mm4 boots fine.  Its really not obvious to
> me at all why that patch is breaking things though...

FWIW this fixes mine as well.

-serge

Re: 2.6.15-mm4 failure on power5

[Michael Ellerman]

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

On Tue, 17 Jan 2006 08:52, Dave C Boutcher wrote:
> 2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
> following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch
>
> If I revert just that patch, mm4 boots fine.  Its really not obvious to
> me at all why that patch is breaking things though...

My POWER5 (gr) LPAR seems to boot ok (3 times so far) with that patch, guess 
it's something subtle. That's with CONFIG_DEBUG_MUTEXES=y. And it's just 
booted once with CONFIG_DEBUG_MUTEXES=n.

And now it's booted the full mm4 patch set without blinking.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Tue, 17 Jan 2006 08:52, Dave C Boutcher wrote:
> > 2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
> > following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch
> >
> > If I revert just that patch, mm4 boots fine.  Its really not obvious to
> > me at all why that patch is breaking things though...
> 
> My POWER5 (gr) LPAR seems to boot ok (3 times so far) with that patch, 
> guess it's something subtle. That's with CONFIG_DEBUG_MUTEXES=y. And 
> it's just booted once with CONFIG_DEBUG_MUTEXES=n.
> 
> And now it's booted the full mm4 patch set without blinking.

so it booted fine with CONFIG_DEBUG_MUTEXES=n but with that patch not 
applied?

the patch will likely work around the bug, so DEBUG_MUTEXES=y/n should 
make no difference with that patch applied.

	Ingo

Re: 2.6.15-mm4 failure on power5

[Michael Ellerman]

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

On Wed, 18 Jan 2006 01:00, Ingo Molnar wrote:
> * Michael Ellerman <michael@ellerman.id.au> wrote:
> > On Tue, 17 Jan 2006 08:52, Dave C Boutcher wrote:
> > > 2.6.15-mm4 won't boot on my power5 either.  I tracked it down to the
> > > following mutex patch from Ingo: kernel-kernel-cpuc-to-mutexes.patch
> > >
> > > If I revert just that patch, mm4 boots fine.  Its really not obvious to
> > > me at all why that patch is breaking things though...
> >
> > My POWER5 (gr) LPAR seems to boot ok (3 times so far) with that patch,
> > guess it's something subtle. That's with CONFIG_DEBUG_MUTEXES=y. And
> > it's just booted once with CONFIG_DEBUG_MUTEXES=n.
> >
> > And now it's booted the full mm4 patch set without blinking.
>
> so it booted fine with CONFIG_DEBUG_MUTEXES=n but with that patch not
> applied?
>
> the patch will likely work around the bug, so DEBUG_MUTEXES=y/n should
> make no difference with that patch applied.

It booted fine _with_ the patch applied, with DEBUG_MUTEXES=y and n.

Boutcher, to be clear, you can't boot with kernel-kernel-cpuc-to-mutexes.patch 
applied and DEBUG_MUTEXES=y ?

But if you revert kernel-kernel-cpuc-to-mutexes.patch it boots ok?

This is looking quite similar to another hang we're seeing on Power4 iSeries 
on mainline git:
http://ozlabs.org/pipermail/linuxppc64-dev/2006-January/007679.html

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-mm4 failure on power5

[Dave C Boutcher]

On Wed, Jan 18, 2006 at 11:19:36AM +1100, Michael Ellerman wrote:
> It booted fine _with_ the patch applied, with DEBUG_MUTEXES=y and n.
> 
> Boutcher, to be clear, you can't boot with kernel-kernel-cpuc-to-mutexes.patch 
> applied and DEBUG_MUTEXES=y ?
> 
> But if you revert kernel-kernel-cpuc-to-mutexes.patch it boots ok?
> 
> This is looking quite similar to another hang we're seeing on Power4 iSeries 
> on mainline git:
> http://ozlabs.org/pipermail/linuxppc64-dev/2006-January/007679.html

Correct...I die in exactly the same place every time with
DEBUG_MUTEXES=Y.  I posted a backtrace that points into the _lock_cpu
code, but I haven't really dug into the issue yet.  I believe this is
very timing related (Serge was dying slightly differently).

-- 
Dave Boutcher

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Dave C Boutcher <sleddog@us.ibm.com> wrote:

> On Wed, Jan 18, 2006 at 11:19:36AM +1100, Michael Ellerman wrote:
> > It booted fine _with_ the patch applied, with DEBUG_MUTEXES=y and n.
> > 
> > Boutcher, to be clear, you can't boot with kernel-kernel-cpuc-to-mutexes.patch 
> > applied and DEBUG_MUTEXES=y ?
> > 
> > But if you revert kernel-kernel-cpuc-to-mutexes.patch it boots ok?
> > 
> > This is looking quite similar to another hang we're seeing on Power4 iSeries 
> > on mainline git:
> > http://ozlabs.org/pipermail/linuxppc64-dev/2006-January/007679.html
> 
> Correct...I die in exactly the same place every time with 
> DEBUG_MUTEXES=Y.  I posted a backtrace that points into the _lock_cpu 
> code, but I haven't really dug into the issue yet.  I believe this is 
> very timing related (Serge was dying slightly differently).

so my question still is: _without_ the workaround patch, i.e. with 
vanilla -mm4, and DEBUG_MUTEXES=n, do you get a hang?

the reason for my question is that DEBUG_MUTEXES=y will e.g. enable 
interrupts - so buggy early bootup code which relies on interrupts being 
off might be surprised by it. The fact that you observed that it's 
somehow related to the timer interrupt seems to strengthen this 
suspicion. DEBUG_MUTEXES=n on the other hand should have no such 
interrupt-enabling effects.

[ if this indeed is the case then i'll add irqs_off() checks to
  DEBUG_MUTEXES=y, to ensure that the mutex APIs are never called with 
  interrupts disabled. ]

	Ingo

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Dave C Boutcher <sleddog@us.ibm.com> wrote:
> 
> > On Wed, Jan 18, 2006 at 11:19:36AM +1100, Michael Ellerman wrote:
> > > It booted fine _with_ the patch applied, with DEBUG_MUTEXES=y and n.
> > > 
> > > Boutcher, to be clear, you can't boot with kernel-kernel-cpuc-to-mutexes.patch 
> > > applied and DEBUG_MUTEXES=y ?
> > > 
> > > But if you revert kernel-kernel-cpuc-to-mutexes.patch it boots ok?
> > > 
> > > This is looking quite similar to another hang we're seeing on Power4 iSeries 
> > > on mainline git:
> > > http://ozlabs.org/pipermail/linuxppc64-dev/2006-January/007679.html
> > 
> > Correct...I die in exactly the same place every time with 
> > DEBUG_MUTEXES=Y.  I posted a backtrace that points into the _lock_cpu 
> > code, but I haven't really dug into the issue yet.  I believe this is 
> > very timing related (Serge was dying slightly differently).
> 
> so my question still is: _without_ the workaround patch, i.e. with 
> vanilla -mm4, and DEBUG_MUTEXES=n, do you get a hang?
> 
> the reason for my question is that DEBUG_MUTEXES=y will e.g. enable 
> interrupts

That used to kill ppc64 and yes, it died in timer interrupts.

> - so buggy early bootup code which relies on interrupts being 
> off might be surprised by it.

I don't think it's necessarily buggy that bootup code needs interrupts
disabled.  It _is_ buggy that bootup code which needs interrupts disabled
is calling lock_cpu_hotplug().

> The fact that you observed that it's 
> somehow related to the timer interrupt seems to strengthen this 
> suspicion. DEBUG_MUTEXES=n on the other hand should have no such 
> interrupt-enabling effects.
> 
> [ if this indeed is the case then i'll add irqs_off() checks to
>   DEBUG_MUTEXES=y, to ensure that the mutex APIs are never called with 
>   interrupts disabled. ]

Yes, I suppose so.  But we're already calling might_sleep(), and
might_sleep() checks for that.  Perhaps the might_sleep() check is being
defeated by the nasty system_running check.

There's a sad story behind that system_running check in might_sleep(). 
Because the kernel early boot is running in an in_atomic() state, a great
number of bogus might_sleep() warnings come out because of various code
doing potentially-sleepy things.  I ended up adding the system_running
test, with the changelog "OK, I give up.  Kill all the might_sleep warnings
from the early boot process." Undoing that and fixing up the fallout would
be a lot of nasty work.

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > [ if this indeed is the case then i'll add irqs_off() checks to
> >   DEBUG_MUTEXES=y, to ensure that the mutex APIs are never called with 
> >   interrupts disabled. ]
> 
> Yes, I suppose so.  But we're already calling might_sleep(), and 
> might_sleep() checks for that.  Perhaps the might_sleep() check is 
> being defeated by the nasty system_running check.

ah ... indeed.

> There's a sad story behind that system_running check in might_sleep().  
> Because the kernel early boot is running in an in_atomic() state, a 
> great number of bogus might_sleep() warnings come out because of 
> various code doing potentially-sleepy things.  I ended up adding the 
> system_running test, with the changelog "OK, I give up.  Kill all the 
> might_sleep warnings from the early boot process." Undoing that and 
> fixing up the fallout would be a lot of nasty work.

OTOH, x86 was just fine last i checked, and it has alot more complex 
bootup code than any of the other architectures (due to the sheer number 
of x86 variants).

	Ingo

Re: 2.6.15-mm4 failure on power5

[Nathan Lynch]

Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> > - so buggy early bootup code which relies on interrupts being 
> > off might be surprised by it.
> 
> I don't think it's necessarily buggy that bootup code needs interrupts
> disabled.  It _is_ buggy that bootup code which needs interrupts disabled
> is calling lock_cpu_hotplug().

I guess I don't understand -- why is it wrong for code that runs only
in early early bootup, when there is only one process context, to use
common code to e.g. register a hotplug cpu notifier?  Should the
powerpc numa code be made to wait to register its notifier until
initcall time or something?

> > The fact that you observed that it's 
> > somehow related to the timer interrupt seems to strengthen this 
> > suspicion. DEBUG_MUTEXES=n on the other hand should have no such 
> > interrupt-enabling effects.
> > 
> > [ if this indeed is the case then i'll add irqs_off() checks to
> >   DEBUG_MUTEXES=y, to ensure that the mutex APIs are never called with 
> >   interrupts disabled. ]
> 
> Yes, I suppose so.  But we're already calling might_sleep(), and
> might_sleep() checks for that.  Perhaps the might_sleep() check is being
> defeated by the nasty system_running check.

Yes, which would be why this code never triggered a warning when
cpucontrol was a semaphore.

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

Nathan Lynch <ntl@pobox.com> wrote:
>
> Andrew Morton wrote:
> > Ingo Molnar <mingo@elte.hu> wrote:
> > > - so buggy early bootup code which relies on interrupts being 
> > > off might be surprised by it.
> > 
> > I don't think it's necessarily buggy that bootup code needs interrupts
> > disabled.  It _is_ buggy that bootup code which needs interrupts disabled
> > is calling lock_cpu_hotplug().
> 
> I guess I don't understand -- why is it wrong for code that runs only
> in early early bootup, when there is only one process context, to use
> common code to e.g. register a hotplug cpu notifier?

OK, it's not wrong I guess - we're running code which requires
local_irq_disable() and that code is calling functions which do
local_irq_enable() but we know that those functions won't do that because
there cannot be any lock contention.

So it works, and will continue to work, but it's all rather unpleasant, IMO.

>  Should the
> powerpc numa code be made to wait to register its notifier until
> initcall time or something?

I think the powerpc code is busted, really - it shouldn't be keeling over
like that if someone enables local interrupts.  That being said, it's a
good way of detecting accidental interrupt-enablings.

> Yes, which would be why this code never triggered a warning when
> cpucontrol was a semaphore.

Yup.  Perhaps a sane fix which preserves the unpleasant semantics is to do
irqsave in the mutex debug code.

Re: 2.6.15-mm4 failure on power5

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > Yes, which would be why this code never triggered a warning when
> > cpucontrol was a semaphore.
> 
> Yup.  Perhaps a sane fix which preserves the unpleasant semantics is 
> to do irqsave in the mutex debug code.

i'd much rather remove that ugly hack from __might_sleep(). How many 
other bugs does it hide? Does it hide bugs that dont normally trigger 
during bootups on real hardware, but which could trigger on e.g. UML or 
on Xen? I really think such ugly workarounds are not justified, if other 
arches can get their act together. Would you make such an exception for 
other arches too, like ARM?

an irqsave in the mutex debug code will uglify the kernel/mutex.c code - 
i'd have to add extra "unsigned long flags" lines. [It will also slow 
down the debug code a bit - an extra PUSHF has to be done.]

	Ingo

Re: 2.6.15-mm4 failure on power5

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > Yes, which would be why this code never triggered a warning when
> > > cpucontrol was a semaphore.
> > 
> > Yup.  Perhaps a sane fix which preserves the unpleasant semantics is 
> > to do irqsave in the mutex debug code.
> 
> i'd much rather remove that ugly hack from __might_sleep(). How many 
> other bugs does it hide?

Gee, it was 2.6.0-test9.  I don't remember, but I do recall the problems
were really really nasty, and what's the point?  We're only running one
thread on one CPU at that time, so none of these things _will_ sleep.

> Does it hide bugs that dont normally trigger 
> during bootups on real hardware, but which could trigger on e.g. UML or 
> on Xen? I really think such ugly workarounds are not justified, if other 
> arches can get their act together. Would you make such an exception for 
> other arches too, like ARM?

Don't care really, as long as a) the problems don't hit -mm or mainline and
b) someone else fixes them.  Yes, it'd be nice to fix these things, and we
might even find real bugs.  Perhaps things are better now, but I suspect
it's a can of worms.

> an irqsave in the mutex debug code will uglify the kernel/mutex.c code - 
> i'd have to add extra "unsigned long flags" lines. [It will also slow 
> down the debug code a bit - an extra PUSHF has to be done.]

Small cost, really...

[patch] work around ppc64 bootup bug by making mutex-debugging save/restore irqs

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > Does it hide bugs that dont normally trigger 
> > during bootups on real hardware, but which could trigger on e.g. UML or 
> > on Xen? I really think such ugly workarounds are not justified, if other 
> > arches can get their act together. Would you make such an exception for 
> > other arches too, like ARM?
> 
> Don't care really, as long as a) the problems don't hit -mm or 
> mainline and b) someone else fixes them.  Yes, it'd be nice to fix 
> these things, and we might even find real bugs.  Perhaps things are 
> better now, but I suspect it's a can of worms.

patch to mutex code below.

-- 

it seems ppc64 wants to lock mutexes in early bootup code, with 
interrupts disabled, and they expect interrupts to stay disabled, else 
they crash.

work this bug around by making mutex debugging variants save/restore irq 
flags.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 kernel/mutex-debug.c |   12 ++++++------
 kernel/mutex-debug.h |   25 +++++--------------------
 kernel/mutex.c       |   21 ++++++++++++---------
 kernel/mutex.h       |    6 ++++--
 4 files changed, 27 insertions(+), 37 deletions(-)

Index: linux/kernel/mutex-debug.c
===================================================================
--- linux.orig/kernel/mutex-debug.c
+++ linux/kernel/mutex-debug.c
@@ -153,13 +153,13 @@ next:
 			continue;
 		count++;
 		cursor = curr->next;
-		debug_spin_lock_restore(&debug_mutex_lock, flags);
+		debug_spin_unlock_restore(&debug_mutex_lock, flags);
 
 		printk("\n#%03d:            ", count);
 		printk_lock(lock, filter ? 0 : 1);
 		goto next;
 	}
-	debug_spin_lock_restore(&debug_mutex_lock, flags);
+	debug_spin_unlock_restore(&debug_mutex_lock, flags);
 	printk("\n");
 }
 
@@ -316,7 +316,7 @@ void mutex_debug_check_no_locks_held(str
 			continue;
 		list_del_init(curr);
 		DEBUG_OFF();
-		debug_spin_lock_restore(&debug_mutex_lock, flags);
+		debug_spin_unlock_restore(&debug_mutex_lock, flags);
 
 		printk("BUG: %s/%d, lock held at task exit time!\n",
 			task->comm, task->pid);
@@ -325,7 +325,7 @@ void mutex_debug_check_no_locks_held(str
 			printk("exiting task is not even the owner??\n");
 		return;
 	}
-	debug_spin_lock_restore(&debug_mutex_lock, flags);
+	debug_spin_unlock_restore(&debug_mutex_lock, flags);
 }
 
 /*
@@ -352,7 +352,7 @@ void mutex_debug_check_no_locks_freed(co
 			continue;
 		list_del_init(curr);
 		DEBUG_OFF();
-		debug_spin_lock_restore(&debug_mutex_lock, flags);
+		debug_spin_unlock_restore(&debug_mutex_lock, flags);
 
 		printk("BUG: %s/%d, active lock [%p(%p-%p)] freed!\n",
 			current->comm, current->pid, lock, from, to);
@@ -362,7 +362,7 @@ void mutex_debug_check_no_locks_freed(co
 			printk("freeing task is not even the owner??\n");
 		return;
 	}
-	debug_spin_lock_restore(&debug_mutex_lock, flags);
+	debug_spin_unlock_restore(&debug_mutex_lock, flags);
 }
 
 /*
Index: linux/kernel/mutex-debug.h
===================================================================
--- linux.orig/kernel/mutex-debug.h
+++ linux/kernel/mutex-debug.h
@@ -46,21 +46,6 @@ extern void mutex_remove_waiter(struct m
 extern void debug_mutex_unlock(struct mutex *lock);
 extern void debug_mutex_init(struct mutex *lock, const char *name);
 
-#define debug_spin_lock(lock)				\
-	do {						\
-		local_irq_disable();			\
-		if (debug_mutex_on)			\
-			spin_lock(lock);		\
-	} while (0)
-
-#define debug_spin_unlock(lock)				\
-	do {						\
-		if (debug_mutex_on)			\
-			spin_unlock(lock);		\
-		local_irq_enable();			\
-		preempt_check_resched();		\
-	} while (0)
-
 #define debug_spin_lock_save(lock, flags)		\
 	do {						\
 		local_irq_save(flags);			\
@@ -68,7 +53,7 @@ extern void debug_mutex_init(struct mute
 			spin_lock(lock);		\
 	} while (0)
 
-#define debug_spin_lock_restore(lock, flags)		\
+#define debug_spin_unlock_restore(lock, flags)		\
 	do {						\
 		if (debug_mutex_on)			\
 			spin_unlock(lock);		\
@@ -76,20 +61,20 @@ extern void debug_mutex_init(struct mute
 		preempt_check_resched();		\
 	} while (0)
 
-#define spin_lock_mutex(lock)				\
+#define spin_lock_mutex(lock, flags)			\
 	do {						\
 		struct mutex *l = container_of(lock, struct mutex, wait_lock); \
 							\
 		DEBUG_WARN_ON(in_interrupt());		\
-		debug_spin_lock(&debug_mutex_lock);	\
+		debug_spin_lock_save(&debug_mutex_lock, flags); \
 		spin_lock(lock);			\
 		DEBUG_WARN_ON(l->magic != l);		\
 	} while (0)
 
-#define spin_unlock_mutex(lock)				\
+#define spin_unlock_mutex(lock, flags)			\
 	do {						\
 		spin_unlock(lock);			\
-		debug_spin_unlock(&debug_mutex_lock);	\
+		debug_spin_unlock_restore(&debug_mutex_lock, flags);	\
 	} while (0)
 
 #define DEBUG_OFF()					\
Index: linux/kernel/mutex.c
===================================================================
--- linux.orig/kernel/mutex.c
+++ linux/kernel/mutex.c
@@ -125,10 +125,11 @@ __mutex_lock_common(struct mutex *lock, 
 	struct task_struct *task = current;
 	struct mutex_waiter waiter;
 	unsigned int old_val;
+	unsigned long flags;
 
 	debug_mutex_init_waiter(&waiter);
 
-	spin_lock_mutex(&lock->wait_lock);
+	spin_lock_mutex(&lock->wait_lock, flags);
 
 	debug_mutex_add_waiter(lock, &waiter, task->thread_info, ip);
 
@@ -157,7 +158,7 @@ __mutex_lock_common(struct mutex *lock, 
 		if (unlikely(state == TASK_INTERRUPTIBLE &&
 						signal_pending(task))) {
 			mutex_remove_waiter(lock, &waiter, task->thread_info);
-			spin_unlock_mutex(&lock->wait_lock);
+			spin_unlock_mutex(&lock->wait_lock, flags);
 
 			debug_mutex_free_waiter(&waiter);
 			return -EINTR;
@@ -165,9 +166,9 @@ __mutex_lock_common(struct mutex *lock, 
 		__set_task_state(task, state);
 
 		/* didnt get the lock, go to sleep: */
-		spin_unlock_mutex(&lock->wait_lock);
+		spin_unlock_mutex(&lock->wait_lock, flags);
 		schedule();
-		spin_lock_mutex(&lock->wait_lock);
+		spin_lock_mutex(&lock->wait_lock, flags);
 	}
 
 	/* got the lock - rejoice! */
@@ -178,7 +179,7 @@ __mutex_lock_common(struct mutex *lock, 
 	if (likely(list_empty(&lock->wait_list)))
 		atomic_set(&lock->count, 0);
 
-	spin_unlock_mutex(&lock->wait_lock);
+	spin_unlock_mutex(&lock->wait_lock, flags);
 
 	debug_mutex_free_waiter(&waiter);
 
@@ -203,10 +204,11 @@ static fastcall noinline void
 __mutex_unlock_slowpath(atomic_t *lock_count __IP_DECL__)
 {
 	struct mutex *lock = container_of(lock_count, struct mutex, count);
+	unsigned long flags;
 
 	DEBUG_WARN_ON(lock->owner != current_thread_info());
 
-	spin_lock_mutex(&lock->wait_lock);
+	spin_lock_mutex(&lock->wait_lock, flags);
 
 	/*
 	 * some architectures leave the lock unlocked in the fastpath failure
@@ -231,7 +233,7 @@ __mutex_unlock_slowpath(atomic_t *lock_c
 
 	debug_mutex_clear_owner(lock);
 
-	spin_unlock_mutex(&lock->wait_lock);
+	spin_unlock_mutex(&lock->wait_lock, flags);
 }
 
 /*
@@ -276,9 +278,10 @@ __mutex_lock_interruptible_slowpath(atom
 static inline int __mutex_trylock_slowpath(atomic_t *lock_count)
 {
 	struct mutex *lock = container_of(lock_count, struct mutex, count);
+	unsigned long flags;
 	int prev;
 
-	spin_lock_mutex(&lock->wait_lock);
+	spin_lock_mutex(&lock->wait_lock, flags);
 
 	prev = atomic_xchg(&lock->count, -1);
 	if (likely(prev == 1))
@@ -287,7 +290,7 @@ static inline int __mutex_trylock_slowpa
 	if (likely(list_empty(&lock->wait_list)))
 		atomic_set(&lock->count, 0);
 
-	spin_unlock_mutex(&lock->wait_lock);
+	spin_unlock_mutex(&lock->wait_lock, flags);
 
 	return prev == 1;
 }
Index: linux/kernel/mutex.h
===================================================================
--- linux.orig/kernel/mutex.h
+++ linux/kernel/mutex.h
@@ -9,8 +9,10 @@
  * !CONFIG_DEBUG_MUTEXES case. Most of them are NOPs:
  */
 
-#define spin_lock_mutex(lock)			spin_lock(lock)
-#define spin_unlock_mutex(lock)			spin_unlock(lock)
+#define spin_lock_mutex(lock, flags) \
+		do { spin_lock(lock); (void)(flags); } while (0)
+#define spin_unlock_mutex(lock, flags) \
+		do { spin_unlock(lock); (void)(flags); } while (0)
 #define mutex_remove_waiter(lock, waiter, ti) \
 		__list_del((waiter)->list.prev, (waiter)->list.next)
 

[patch] turn on might_sleep() in early bootup code too

[Ingo Molnar]

Could we try the patch below in -mm, to get a feeling of how widespread 
the early bootup lock-atomicity assumptions are? I also added a .config 
option to add back the workaround, and turned it on for ppc64. (users 
can still select this manually on any other arch as well)

i found one such bug on x86: early-printk calls register_console(), 
which acquires console_sem. Since we can work such things around 
per-lock and per-assumption [see the printk.c changes], i think we 
should rather do the workarounds that way, and thus document the hacks 
we need - without impacting the ability of such platforms to boot - 
while still keeping might_sleep() checks widely enabled. (btw., x86 
still booted fine, despite the warning.)

	Ingo

--

enable might_sleep() checks even in early bootup code (when system_state 
!= SYSTEM_RUNNING). There's also a new config option to turn this off:
CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
while most other architectures.

the patch also documents and works around an EARLY_PRINTK locking 
dependency. [which we might want to get rid of in the future.]

tested on x86.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 arch/powerpc/Kconfig.debug |    2 ++
 kernel/printk.c            |   11 ++++++++++-
 kernel/sched.c             |    7 +++++--
 lib/Kconfig.debug          |   11 +++++++++++
 4 files changed, 28 insertions(+), 3 deletions(-)

Index: linux/arch/powerpc/Kconfig.debug
===================================================================
--- linux.orig/arch/powerpc/Kconfig.debug
+++ linux/arch/powerpc/Kconfig.debug
@@ -2,6 +2,8 @@ menu "Kernel hacking"
 
 source "lib/Kconfig.debug"
 
+select CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+
 config DEBUG_STACKOVERFLOW
 	bool "Check for stack overflows"
 	depends on DEBUG_KERNEL && PPC64
Index: linux/kernel/printk.c
===================================================================
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -710,7 +710,16 @@ void acquire_console_sem(void)
 {
 	if (in_interrupt())
 		BUG();
-	down(&console_sem);
+	/*
+	 * Early-printk wants to acquire the console_sem in
+	 * register_console(). Make a special exception for them by
+	 * going via trylock first, which doesnt trigger the
+	 * might_sleep() atomicity check.
+	 */
+#ifdef CONFIG_EARLY_PRINTK
+	if (down_trylock(&console_sem))
+#endif
+		down(&console_sem);
 	console_locked = 1;
 	console_may_schedule = 1;
 }
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -6285,8 +6285,11 @@ void __might_sleep(char *file, int line)
 #if defined(in_atomic)
 	static unsigned long prev_jiffy;	/* ratelimiting */
 
-	if ((in_atomic() || irqs_disabled()) &&
-	    system_state == SYSTEM_RUNNING && !oops_in_progress) {
+#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+	if (system_state != SYSTEM_RUNNING)
+		return;
+#endif
+	if ((in_atomic() || irqs_disabled()) && !oops_in_progress) {
 		if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
 			return;
 		prev_jiffy = jiffies;
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -128,6 +128,17 @@ config DEBUG_SPINLOCK_SLEEP
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.
 
+config DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+	bool "Work around sleep-inside-spinlock checking in early bootup code"
+	depends on DEBUG_SPINLOCK_SLEEP
+	help
+	  If you say Y here, then early bootup code will not check for
+	  "do not call potentially sleeping functions in atomic sections"
+	  rule, that the DEBUG_SPINLOCK_SLEEP option enforces.
+
+	  You want to say N here, unless your system does not boot with
+	  "Y" here.
+
 config DEBUG_KOBJECT
 	bool "kobject debugging"
 	depends on DEBUG_KERNEL

Re: [patch] turn on might_sleep() in early bootup code too

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
>  enable might_sleep() checks even in early bootup code (when system_state 
>  != SYSTEM_RUNNING). There's also a new config option to turn this off:
>  CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
>  while most other architectures.

I get just the one on ppc64:


Debug: sleeping function called from invalid context at include/asm/semaphore.h:62
in_atomic():1, irqs_disabled():1
Call Trace:
[C0000000004EFD20] [C00000000000F660] .show_stack+0x5c/0x1cc (unreliable)
[C0000000004EFDD0] [C000000000053214] .__might_sleep+0xbc/0xe0
[C0000000004EFE60] [C000000000413D1C] .lock_kernel+0x50/0xb0
[C0000000004EFEF0] [C0000000004AC574] .start_kernel+0x1c/0x278
[C0000000004EFF90] [C0000000000085D4] .hmt_init+0x0/0x2c


Your fault ;)

Re: [patch] turn on might_sleep() in early bootup code too

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> Ingo Molnar <mingo@elte.hu> wrote:
> >
> >  enable might_sleep() checks even in early bootup code (when system_state 
> >  != SYSTEM_RUNNING). There's also a new config option to turn this off:
> >  CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
> >  while most other architectures.
> 
> I get just the one on ppc64:
> 
> 
> Debug: sleeping function called from invalid context at include/asm/semaphore.h:62
> in_atomic():1, irqs_disabled():1
> Call Trace:
> [C0000000004EFD20] [C00000000000F660] .show_stack+0x5c/0x1cc (unreliable)
> [C0000000004EFDD0] [C000000000053214] .__might_sleep+0xbc/0xe0
> [C0000000004EFE60] [C000000000413D1C] .lock_kernel+0x50/0xb0
> [C0000000004EFEF0] [C0000000004AC574] .start_kernel+0x1c/0x278
> [C0000000004EFF90] [C0000000000085D4] .hmt_init+0x0/0x2c
> 
> 
> Your fault ;)

yes :-) I have a really ugly workaround in my tree that is definitely 
not worth posting. I think to do this cleanly i'll add trylock_kernel(), 
and do this in main.c:

   BUG_ON(!trylock_kernel());

but there's another one that is much nastier in terms of scope:

BUG: sleeping function called from invalid context at kernel/mutex.c:256
in_atomic():0, irqs_disabled():1
 [<c0103db6>] show_trace+0xd/0xf
 [<c0103dcd>] dump_stack+0x15/0x17
 [<c011ff4b>] __might_sleep+0x64/0x6c
 [<c105b470>] mutex_lock_interruptible+0x15/0x22
 [<c013d81f>] __lock_cpu_hotplug+0x26/0x52
 [<c013d858>] lock_cpu_hotplug_interruptible+0xd/0xf
 [<c013d922>] register_cpu_notifier+0xc/0x2b
 [<c1dac88f>] page_alloc_init+0xd/0xf
 [<c1d992ee>] start_kernel+0x125/0x376
 [<c0100210>] 0xc0100210

this is what is causing the ppc64 problems too i think.

lock_cpu_hotplug() has design problems i think: hotplug-locked sections 
are slowly spreading in the kernel, encompassing more and more code :-) 
Shouldnt the CPU hotplug lock be a spinlock to begin with?

	Ingo

[patch] make bug messages more consistent

[Ingo Molnar]

while we are changing debugging code. One problem is that we've got a 
hodgepodge of bug messages right now, and i frequently miss e.g.  
'Badness' messages from the kernel because they simply do not stick out 
visually. 'BUG' is much more apparent and also makes it obvious that 
there's a kernel bug here. Here's a patch that makes the messages more 
consistent:

--

consolidate all kernel bug printouts to begin with the "BUG: " string.  
Makes it easier to find them in large bootup logs.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 include/asm-generic/bug.h |    4 ++--
 kernel/sched.c            |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Index: linux/include/asm-generic/bug.h
===================================================================
--- linux.orig/include/asm-generic/bug.h
+++ linux/include/asm-generic/bug.h
@@ -7,7 +7,7 @@
 #ifdef CONFIG_BUG
 #ifndef HAVE_ARCH_BUG
 #define BUG() do { \
-	printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
+	printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
 	panic("BUG!"); \
 } while (0)
 #endif
@@ -19,7 +19,7 @@
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) do { \
 	if (unlikely((condition)!=0)) { \
-		printk("Badness in %s at %s:%d\n", __FUNCTION__, __FILE__, __LINE__); \
+		printk("BUG: warning at %s:%d/%s()\n", __FILE__, __LINE__, __FUNCTION__); \
 		dump_stack(); \
 	} \
 } while (0)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -2973,7 +2973,7 @@ asmlinkage void __sched schedule(void)
 	 */
 	if (likely(!current->exit_state)) {
 		if (unlikely(in_atomic())) {
-			printk(KERN_ERR "scheduling while atomic: "
+			printk(KERN_ERR "BUG: scheduling while atomic: "
 				"%s/0x%08x/%d\n",
 				current->comm, preempt_count(), current->pid);
 			dump_stack();
@@ -6293,7 +6293,7 @@ void __might_sleep(char *file, int line)
 		if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
 			return;
 		prev_jiffy = jiffies;
-		printk(KERN_ERR "Debug: sleeping function called from invalid"
+		printk(KERN_ERR "BUG: sleeping function called from invalid"
 				" context at %s:%d\n", file, line);
 		printk("in_atomic():%d, irqs_disabled():%d\n",
 			in_atomic(), irqs_disabled());

Re: [patch] turn on might_sleep() in early bootup code too

[Zwane Mwaikambo]

On Wed, 18 Jan 2006, Ingo Molnar wrote:

> lock_cpu_hotplug() has design problems i think: hotplug-locked sections 
> are slowly spreading in the kernel, encompassing more and more code :-) 
> Shouldnt the CPU hotplug lock be a spinlock to begin with?

The way it's used certainly is bizarre, but a spinlock would be harder to 
work with as a lot of the code protected by it sleep.

Re: [patch] turn on might_sleep() in early bootup code too

[Nick Piggin]

Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> 
>> enable might_sleep() checks even in early bootup code (when system_state 
>> != SYSTEM_RUNNING). There's also a new config option to turn this off:
>> CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
>> while most other architectures.
> 
> 
> I get just the one on ppc64:
> 
> 
> Debug: sleeping function called from invalid context at include/asm/semaphore.h:62
> in_atomic():1, irqs_disabled():1
> Call Trace:
> [C0000000004EFD20] [C00000000000F660] .show_stack+0x5c/0x1cc (unreliable)
> [C0000000004EFDD0] [C000000000053214] .__might_sleep+0xbc/0xe0
> [C0000000004EFE60] [C000000000413D1C] .lock_kernel+0x50/0xb0
> [C0000000004EFEF0] [C0000000004AC574] .start_kernel+0x1c/0x278
> [C0000000004EFF90] [C0000000000085D4] .hmt_init+0x0/0x2c
> 
> 
> Your fault ;)

This lock_kernel should never sleep should it? Maybe it could be changed
to lock_kernel_init_locked() or something?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch] turn on might_sleep() in early bootup code too

[Ingo Molnar]

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Andrew Morton wrote:
> >Ingo Molnar <mingo@elte.hu> wrote:
> >
> >>enable might_sleep() checks even in early bootup code (when system_state 
> >>!= SYSTEM_RUNNING). There's also a new config option to turn this off:
> >>CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
> >>while most other architectures.
> >
> >
> >I get just the one on ppc64:
> >
> >
> >Debug: sleeping function called from invalid context at 
> >include/asm/semaphore.h:62
> >in_atomic():1, irqs_disabled():1
> >Call Trace:
> >[C0000000004EFD20] [C00000000000F660] .show_stack+0x5c/0x1cc (unreliable)
> >[C0000000004EFDD0] [C000000000053214] .__might_sleep+0xbc/0xe0
> >[C0000000004EFE60] [C000000000413D1C] .lock_kernel+0x50/0xb0
> >[C0000000004EFEF0] [C0000000004AC574] .start_kernel+0x1c/0x278
> >[C0000000004EFF90] [C0000000000085D4] .hmt_init+0x0/0x2c
> >
> >
> >Your fault ;)
> 
> This lock_kernel should never sleep should it? Maybe it could be 
> changed to lock_kernel_init_locked() or something?

the way i fixed it in my tree was to add a trylock_kernel(), and to 
check for success in init/main.c. See the patch below.

	Ingo

--

introduce trylock_kernel(), to be used by the early init code to acquire 
the BKL in an atomic way.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

Index: linux/include/linux/smp_lock.h
===================================================================
--- linux.orig/include/linux/smp_lock.h
+++ linux/include/linux/smp_lock.h
@@ -39,6 +39,7 @@ static inline int reacquire_kernel_lock(
 }
 
 extern void __lockfunc lock_kernel(void)	__acquires(kernel_lock);
+extern int __lockfunc trylock_kernel(void);
 extern void __lockfunc unlock_kernel(void)	__releases(kernel_lock);
 
 #else
Index: linux/init/main.c
===================================================================
--- linux.orig/init/main.c
+++ linux/init/main.c
@@ -443,11 +443,14 @@ asmlinkage void __init start_kernel(void
 {
 	char * command_line;
 	extern struct kernel_param __start___param[], __stop___param[];
-/*
- * Interrupts are still disabled. Do necessary setups, then
- * enable them
- */
-	lock_kernel();
+
+	/*
+	 * Interrupts are still disabled. Do necessary setups, then
+	 * enable them. This is the first time we take the BKL, so
+	 * it must succeed:
+	 */
+	if (!trylock_kernel())
+		WARN_ON(1);
 	page_address_init();
 	printk(KERN_NOTICE);
 	printk(linux_banner);
@@ -466,6 +469,7 @@ asmlinkage void __init start_kernel(void
 	 * time - but meanwhile we still have a functioning scheduler.
 	 */
 	sched_init();
+	mutex_key_hash_init();
 	/*
 	 * Disable preemption - early bootup scheduling is extremely
 	 * fragile until we cpu_idle() for the first time.
Index: linux/lib/kernel_lock.c
===================================================================
--- linux.orig/lib/kernel_lock.c
+++ linux/lib/kernel_lock.c
@@ -76,6 +76,23 @@ void __lockfunc lock_kernel(void)
 	task->lock_depth = depth;
 }
 
+int __lockfunc trylock_kernel(void)
+{
+	struct task_struct *task = current;
+	int depth = task->lock_depth + 1;
+
+	if (likely(!depth)) {
+		if (unlikely(down_trylock(&kernel_sem)))
+			return 0;
+		else
+			__acquire(kernel_sem);
+	}
+
+	task->lock_depth = depth;
+	return 1;
+}
+
+
 void __lockfunc unlock_kernel(void)
 {
 	struct task_struct *task = current;
@@ -194,6 +211,25 @@ void __lockfunc lock_kernel(void)
 	current->lock_depth = depth;
 }
 
+int __lockfunc trylock_kernel(void)
+{
+	struct task_struct *task = current;
+	int depth = task->lock_depth + 1;
+
+	if (likely(!depth)) {
+		if (unlikely(!spin_trylock(&kernel_flag)))
+			return 0;
+		else
+			__acquire(kernel_sem);
+	}
+
+	if (likely(!depth) && unlikely(!spin_trylock(&kernel_flag)))
+		return 0;
+
+	task->lock_depth = depth;
+	return 1;
+}
+
 void __lockfunc unlock_kernel(void)
 {
 	BUG_ON(current->lock_depth < 0);
@@ -204,5 +240,6 @@ void __lockfunc unlock_kernel(void)
 #endif
 
 EXPORT_SYMBOL(lock_kernel);
+/* we do not export trylock_kernel(). BKL code should shrink :-) */
 EXPORT_SYMBOL(unlock_kernel);
 

[patch] add trylock_kernel()

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> the way i fixed it in my tree was to add a trylock_kernel(), and to 
> check for success in init/main.c. See the patch below.

i had a silly bug in the spinlock variant, and some extra unneeded 
change from another debug patch - fixed patch is below. Tested on x86, 
with and without CONFIG_PREEMPT_BKL.

	Ingo

--
introduce trylock_kernel(), to be used by the early init code to acquire 
the BKL in an atomic way.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

 include/linux/smp_lock.h |    1 +
 init/main.c              |   13 ++++++++-----
 lib/kernel_lock.c        |   34 ++++++++++++++++++++++++++++++++++
 3 files changed, 43 insertions(+), 5 deletions(-)

Index: linux/include/linux/smp_lock.h
===================================================================
--- linux.orig/include/linux/smp_lock.h
+++ linux/include/linux/smp_lock.h
@@ -39,6 +39,7 @@ static inline int reacquire_kernel_lock(
 }
 
 extern void __lockfunc lock_kernel(void)	__acquires(kernel_lock);
+extern int __lockfunc trylock_kernel(void);
 extern void __lockfunc unlock_kernel(void)	__releases(kernel_lock);
 
 #else
Index: linux/init/main.c
===================================================================
--- linux.orig/init/main.c
+++ linux/init/main.c
@@ -443,11 +443,14 @@ asmlinkage void __init start_kernel(void
 {
 	char * command_line;
 	extern struct kernel_param __start___param[], __stop___param[];
-/*
- * Interrupts are still disabled. Do necessary setups, then
- * enable them
- */
-	lock_kernel();
+
+	/*
+	 * Interrupts are still disabled. Do necessary setups, then
+	 * enable them. This is the first time we take the BKL, so
+	 * it must succeed:
+	 */
+	if (!trylock_kernel())
+		WARN_ON(1);
 	page_address_init();
 	printk(KERN_NOTICE);
 	printk(linux_banner);
Index: linux/lib/kernel_lock.c
===================================================================
--- linux.orig/lib/kernel_lock.c
+++ linux/lib/kernel_lock.c
@@ -76,6 +76,23 @@ void __lockfunc lock_kernel(void)
 	task->lock_depth = depth;
 }
 
+int __lockfunc trylock_kernel(void)
+{
+	struct task_struct *task = current;
+	int depth = task->lock_depth + 1;
+
+	if (likely(!depth)) {
+		if (unlikely(down_trylock(&kernel_sem)))
+			return 0;
+		else
+			__acquire(kernel_sem);
+	}
+
+	task->lock_depth = depth;
+	return 1;
+}
+
+
 void __lockfunc unlock_kernel(void)
 {
 	struct task_struct *task = current;
@@ -194,6 +211,22 @@ void __lockfunc lock_kernel(void)
 	current->lock_depth = depth;
 }
 
+int __lockfunc trylock_kernel(void)
+{
+	struct task_struct *task = current;
+	int depth = task->lock_depth + 1;
+
+	if (likely(!depth)) {
+		if (unlikely(!spin_trylock(&kernel_flag)))
+			return 0;
+		else
+			__acquire(kernel_sem);
+	}
+
+	task->lock_depth = depth;
+	return 1;
+}
+
 void __lockfunc unlock_kernel(void)
 {
 	BUG_ON(current->lock_depth < 0);
@@ -204,5 +237,6 @@ void __lockfunc unlock_kernel(void)
 #endif
 
 EXPORT_SYMBOL(lock_kernel);
+/* we do not export trylock_kernel(). BKL code should shrink :-) */
 EXPORT_SYMBOL(unlock_kernel);
 

Re: 2.6.15-mm4 failure on power5

[Arjan van de Ven]

On Wed, 2006-01-18 at 01:28 -0600, Nathan Lynch wrote:
> Andrew Morton wrote:
> > Ingo Molnar <mingo@elte.hu> wrote:
> > > - so buggy early bootup code which relies on interrupts being 
> > > off might be surprised by it.
> > 
> > I don't think it's necessarily buggy that bootup code needs interrupts
> > disabled.  It _is_ buggy that bootup code which needs interrupts disabled
> > is calling lock_cpu_hotplug().
> 
> I guess I don't understand -- why is it wrong for code that runs only
> in early early bootup, when there is only one process context, to use
> common code to e.g. register a hotplug cpu notifier? 

it's nasty to use things-that-can-sleep there though.
Even if that sleep is a bit theoretical, it still isn't nice.