* kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 13:26 Toralf Förster
2011-05-19 16:34 ` Toralf Förster
2011-05-19 17:00 ` richard -rw- weinberger
0 siblings, 2 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 13:26 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: Text/Plain, Size: 1411 bytes --]
I got a segfault as soon as I try to access the phpmyadmin web page of the UML
instance at https://<uml_hostname>/phpmyadmin/ :
/home/tfoerste/workspace/bin/start_uml.sh: line 72: 21972 Segmentation fault
(core dumped) sh -c "$LINUX ubda=$ROOT_FS ubdb=$SWAP_FS $CD eth0=tuntap,,,$TAP
mem=256M $TTY $*"
A core file is produced, but seems not to have usefull info in it:
tfoerste@n22 ~ $ gdb --core=core
GNU gdb (Gentoo 7.2 p1) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
[New Thread 22866]
Failed to read a valid object file image from memory.
Core was generated by `'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x001000ec in ?? ()
(gdb) bt
#0 0x001000ec in ?? ()
#1 0x00101aa8 in ?? ()
#2 0xb78b2400 in ?? ()
#3 0x0000000b in ?? ()
#4 0x00000033 in ?? ()
#5 0x00000000 in ?? ()
Which kernel option I should activate to get more info in the core file ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: showconfig --]
[-- Type: text/plain, Size: 18771 bytes --]
#
# Automatically generated make config: don't edit
# Linux Kernel Configuration
# Wed May 18 23:20:19 2011
#
CONFIG_DEFCONFIG_LIST="arch/$ARCH/defconfig"
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_NO_IOMEM=y
# CONFIG_TRACE_IRQFLAGS_SUPPORT is not set
CONFIG_LOCKDEP_SUPPORT=y
# CONFIG_STACKTRACE_SUPPORT is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_IRQ_RELEASE_METHOD=y
CONFIG_HZ=100
#
# UML-specific options
#
#
# Host processor type and features
#
# CONFIG_CMPXCHG_LOCAL is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_MCORE2=y
# CONFIG_MATOM is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_UML_X86=y
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
# CONFIG_SMP_BROKEN is not set
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_STATIC_LINK is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_NEED_PER_CPU_KM=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_LD_SCRIPT_DYN=y
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_HOSTFS=y
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_KERNEL_STACK_ORDER=0
CONFIG_NO_DMA=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=128
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_SHOW=y
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_NS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
#
# Kernel Performance Events And Counters
#
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_PROFILING is not set
#
# GCOV-based kernel profiling
#
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_FREEZER is not set
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_UBD=y
# CONFIG_BLK_DEV_UBD_SYNC is not set
CONFIG_BLK_DEV_COW_COMMON=y
# CONFIG_BLK_DEV_LOOP is not set
#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_RBD is not set
#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
# CONFIG_NOCONFIG_CHAN is not set
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pts"
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_WATCHDOG is not set
CONFIG_UML_SOUND=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_HOSTAUDIO=y
# CONFIG_HW_RANDOM is not set
# CONFIG_UML_RANDOM is not set
# CONFIG_MMAPPER is not set
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_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 set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# 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 is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV 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_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
#
# UML Network Devices
#
CONFIG_UML_NET=y
CONFIG_UML_NET_ETHERTAP=y
CONFIG_UML_NET_TUNTAP=y
CONFIG_UML_NET_SLIP=y
CONFIG_UML_NET_DAEMON=y
# CONFIG_UML_NET_VDE is not set
CONFIG_UML_NET_MCAST=y
# CONFIG_UML_NET_PCAP is not set
CONFIG_UML_NET_SLIRP=y
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_MII is not set
# CONFIG_PHYLIB is not set
# CONFIG_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
#
# CAIF transport drivers
#
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_CONNECTOR is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS 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_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_PNFS_FILE_LAYOUT=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_USE_NEW_IDMAPPER=y
CONFIG_NFSD=y
CONFIG_NFSD_DEPRECATED=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_CEPH_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
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY_DMESG_RESTRICT=y
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC 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=y
# 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 is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_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 set
# CONFIG_CRYPTO_SHA1 is not set
# 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_AES_NI_INTEL 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=y
# 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_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_NLATTR=y
# CONFIG_AVERAGE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_MD is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INPUT is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_DEBUG_STACK_USAGE is not set
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 13:26 kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine) Toralf Förster
@ 2011-05-19 16:34 ` Toralf Förster
2011-05-20 6:44 ` richard -rw- weinberger
2011-05-19 17:00 ` richard -rw- weinberger
1 sibling, 1 reply; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 16:34 UTC (permalink / raw)
To: linux-kernel
FWIW I got :
* Starting local
Kernel panic - not syncing: Segfault with no mm
08335ed4: [<082b0b3b>] dump_stack+0x22/0x24
08335eec: [<082b0ba0>] panic+0x63/0x167
08335f14: [<080614af>] segv+0x27f/0x2f0
08335fcc: [<08061561>] segv_handler+0x41/0x60
08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
Not tainted
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
08335e88: [<0807935d>] show_regs+0xed/0x120
08335ea4: [<0806179c>] panic_exit+0x2c/0x50
08335eb4: [<080a2b9c>] notifier_call_chain+0x4c/0x70
08335edc: [<080a2c13>] atomic_notifier_call_chain+0x23/0x30
08335eec: [<082b0bc8>] panic+0x8b/0x167
08335f14: [<080614af>] segv+0x27f/0x2f0
08335fcc: [<08061561>] segv_handler+0x41/0x60
08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
and gdb gives in another session to reproduce the bug this:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
rwsem_down_failed_common (sem=0x84f4000, flags=<value optimized out>,
adjustment=<value optimized out>)
at lib/rwsem.c:189
189 adjustment += RWSEM_WAITING_BIAS;
(gdb) bt
#0 rwsem_down_failed_common (sem=0x84f4000, flags=<value optimized out>,
adjustment=<value optimized out>)
at lib/rwsem.c:189
#1 0x082b28f5 in rwsem_down_write_failed (sem=0x84f4000) at lib/rwsem.c:236
#2 0x082b0ba2 in call_rwsem_down_write_failed () at arch/um/sys-
i386/../../x86/lib/semaphore_32.S:92
#3 0x082b20e7 in __down_write_nested (sem=0x18916274)
at /home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:105
#4 __down_write (sem=0x18916274) at
/home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:121
#5 down_write (sem=0x18916274) at kernel/rwsem.c:51
#6 0x080d78e5 in sys_brk (brk=139411456) at mm/mmap.c:254
#7 0x08061dc6 in handle_syscall (r=0x19634d50) at
arch/um/kernel/skas/syscall.c:35
#8 0x08075ed1 in handle_trap (regs=0x19634d50) at arch/um/os-
Linux/skas/process.c:201
#9 userspace (regs=0x19634d50) at arch/um/os-Linux/skas/process.c:417
#10 0x0805ef34 in fork_handler () at arch/um/kernel/process.c:181
#11 0x00000000 in ?? ()
(gdb) bt full
#0 rwsem_down_failed_common (sem=0x84f4000, flags=<value optimized out>,
adjustment=<value optimized out>)
at lib/rwsem.c:189
waiter = {list = {next = 0x84cf27c, prev = 0x6}, task = 0x19634b80,
flags = 2}
tsk = 0x19634b80
count = <value optimized out>
#1 0x082b28f5 in rwsem_down_write_failed (sem=0x84f4000) at lib/rwsem.c:236
No locals.
#2 0x082b0ba2 in call_rwsem_down_write_failed () at arch/um/sys-
i386/../../x86/lib/semaphore_32.S:92
No locals.
#3 0x082b20e7 in __down_write_nested (sem=0x18916274)
at /home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:105
tmp = 411836076
#4 __down_write (sem=0x18916274) at
/home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:121
No locals.
#5 down_write (sem=0x18916274) at kernel/rwsem.c:51
No locals.
#6 0x080d78e5 in sys_brk (brk=139411456) at mm/mmap.c:254
rlim = <value optimized out>
newbrk = <value optimized out>
oldbrk = 0
mm = 0x18916240
#7 0x08061dc6 in handle_syscall (r=0x19634d50) at
arch/um/kernel/skas/syscall.c:35
syscall = <value optimized out>
#8 0x08075ed1 in handle_trap (regs=0x19634d50) at arch/um/os-
Linux/skas/process.c:201
err = <value optimized out>
status = 0
#9 userspace (regs=0x19634d50) at arch/um/os-Linux/skas/process.c:417
sig = <value optimized out>
timer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec =
0, tv_usec = 3999}}
nsecs = <value optimized out>
err = <value optimized out>
status = 34175
op = 31
pid = 11337
local_using_sysemu = 2
#10 0x0805ef34 in fork_handler () at arch/um/kernel/process.c:181
No locals.
#11 0x00000000 in ?? ()
No symbol table info available.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 13:26 kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine) Toralf Förster
@ 2011-05-19 17:00 ` richard -rw- weinberger
2011-05-19 17:00 ` richard -rw- weinberger
1 sibling, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-19 17:00 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
Hi,
Please CC also user-mode-linux-devel@lists.sourceforge.net,
so you can reach much more UML users. :)
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> I got a segfault as soon as I try to access the phpmyadmin web page of the UML
> instance at https://<uml_hostname>/phpmyadmin/ :
Hmm, strange.
phpmyadmin works fine on my UML test bed.
Can you bisect the issue?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 17:00 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-19 17:00 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
Hi,
Please CC also user-mode-linux-devel@lists.sourceforge.net,
so you can reach much more UML users. :)
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> I got a segfault as soon as I try to access the phpmyadmin web page of the UML
> instance at https://<uml_hostname>/phpmyadmin/ :
Hmm, strange.
phpmyadmin works fine on my UML test bed.
Can you bisect the issue?
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 17:00 ` richard -rw- weinberger
@ 2011-05-19 17:20 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 17:20 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 19:00:35
> Hi,
>
> Please CC also user-mode-linux-devel@lists.sourceforge.net,
> so you can reach much more UML users. :)
>
> 2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> > I got a segfault as soon as I try to access the phpmyadmin web page of
> > the UML
>
> > instance at https://<uml_hostname>/phpmyadmin/ :
> Hmm, strange.
> phpmyadmin works fine on my UML test bed.
> Can you bisect the issue?
Errm, automatic bisecting doesn't work, b/c the issue can't be reproduced by a
simple "wget https://..." - when I use konqueror - up to 6-10 times I'm asked
to confirm a cookie or something else before the crash occures.
And if I use "lynx -accept_all_cookies https://n22_uml/phpmyadmin/" then I'm
able to login - so it has something to do with HTTP frames I suspected - but a
shutdown of the UML instance wasn't possible too after such a try - probably
something else then the HTTP frames itself triggers the issue ...
In short - it is not phpmyadmin (3.4.0) itself, but it triggers the bug (in
fact sometimes I even could see the login window within Firefox of the
phpmyadmin site before the crash happened).
Because therefore manual interaction is needed (or do you know an automated
way for konqueror/ff/.... ?) at least it would be helpful if the bisecting
could be narrowed doesn to a given path or somethign else.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 17:20 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 17:20 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 19:00:35
> Hi,
>
> Please CC also user-mode-linux-devel@lists.sourceforge.net,
> so you can reach much more UML users. :)
>
> 2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> > I got a segfault as soon as I try to access the phpmyadmin web page of
> > the UML
>
> > instance at https://<uml_hostname>/phpmyadmin/ :
> Hmm, strange.
> phpmyadmin works fine on my UML test bed.
> Can you bisect the issue?
Errm, automatic bisecting doesn't work, b/c the issue can't be reproduced by a
simple "wget https://..." - when I use konqueror - up to 6-10 times I'm asked
to confirm a cookie or something else before the crash occures.
And if I use "lynx -accept_all_cookies https://n22_uml/phpmyadmin/" then I'm
able to login - so it has something to do with HTTP frames I suspected - but a
shutdown of the UML instance wasn't possible too after such a try - probably
something else then the HTTP frames itself triggers the issue ...
In short - it is not phpmyadmin (3.4.0) itself, but it triggers the bug (in
fact sometimes I even could see the login window within Firefox of the
phpmyadmin site before the crash happened).
Because therefore manual interaction is needed (or do you know an automated
way for konqueror/ff/.... ?) at least it would be helpful if the bisecting
could be narrowed doesn to a given path or somethign else.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 17:20 ` Toralf Förster
@ 2011-05-19 17:25 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-19 17:25 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> Errm, automatic bisecting doesn't work, b/c the issue can't be reproduced by a
> simple "wget https://..." - when I use konqueror - up to 6-10 times I'm asked
> to confirm a cookie or something else before the crash occures.
>
> And if I use "lynx -accept_all_cookies https://n22_uml/phpmyadmin/" then I'm
> able to login - so it has something to do with HTTP frames I suspected - but a
> shutdown of the UML instance wasn't possible too after such a try - probably
> something else then the HTTP frames itself triggers the issue ...
>
> In short - it is not phpmyadmin (3.4.0) itself, but it triggers the bug (in
> fact sometimes I even could see the login window within Firefox of the
> phpmyadmin site before the crash happened).
>
> Because therefore manual interaction is needed (or do you know an automated
> way for konqueror/ff/.... ?) at least it would be helpful if the bisecting
> could be narrowed doesn to a given path or somethign else.
BTW: Haven’t you had such an issue a few months ago?
Does it work without https? Maybe mod_ssl triggers the bug...
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 17:25 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-19 17:25 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> Errm, automatic bisecting doesn't work, b/c the issue can't be reproduced by a
> simple "wget https://..." - when I use konqueror - up to 6-10 times I'm asked
> to confirm a cookie or something else before the crash occures.
>
> And if I use "lynx -accept_all_cookies https://n22_uml/phpmyadmin/" then I'm
> able to login - so it has something to do with HTTP frames I suspected - but a
> shutdown of the UML instance wasn't possible too after such a try - probably
> something else then the HTTP frames itself triggers the issue ...
>
> In short - it is not phpmyadmin (3.4.0) itself, but it triggers the bug (in
> fact sometimes I even could see the login window within Firefox of the
> phpmyadmin site before the crash happened).
>
> Because therefore manual interaction is needed (or do you know an automated
> way for konqueror/ff/.... ?) at least it would be helpful if the bisecting
> could be narrowed doesn to a given path or somethign else.
BTW: Haven’t you had such an issue a few months ago?
Does it work without https? Maybe mod_ssl triggers the bug...
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 17:00 ` richard -rw- weinberger
@ 2011-05-19 20:18 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 20:18 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 19:00:35
> Can you bisect the issue?
tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Wed Dec 22 14:18:50 2010 +0800
futex,plist: Pass the real head of the priority list to plist_del()
Some plist_del()s in kernel/futex.c are passed a faked head of the
priority list.
It does not fail because the current code does not require the real head
in plist_del(). The current code of plist_del() just uses the head for
checking,
so it will not cause a bad result even when we use a faked head.
But it is undocumented usage:
/**
* plist_del - Remove a @node from plist.
*
* @node: &struct plist_node pointer - entry to be removed
* @head: &struct plist_head pointer - list head
*/
The document says that the @head is the "list head" head of the priority
list.
In futex code, several places use "plist_del(&q->list, &q->list.plist);",
they pass a fake head. We need to fix them all.
Thanks to Darren Hart for many suggestions.
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
:040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 20:18 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-19 20:18 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 19:00:35
> Can you bisect the issue?
tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Wed Dec 22 14:18:50 2010 +0800
futex,plist: Pass the real head of the priority list to plist_del()
Some plist_del()s in kernel/futex.c are passed a faked head of the
priority list.
It does not fail because the current code does not require the real head
in plist_del(). The current code of plist_del() just uses the head for
checking,
so it will not cause a bad result even when we use a faked head.
But it is undocumented usage:
/**
* plist_del - Remove a @node from plist.
*
* @node: &struct plist_node pointer - entry to be removed
* @head: &struct plist_head pointer - list head
*/
The document says that the @head is the "list head" head of the priority
list.
In futex code, several places use "plist_del(&q->list, &q->list.plist);",
they pass a fake head. We need to fix them all.
Thanks to Darren Hart for many suggestions.
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
:040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 20:18 ` Toralf Förster
@ 2011-05-19 20:43 ` Steven Rostedt
-1 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-19 20:43 UTC (permalink / raw)
To: Toralf Förster; +Cc: richard -rw- weinberger, LKML, user-mode-linux-devel
On Thu, May 19, 2011 at 10:18:16PM +0200, Toralf Förster wrote:
>
> richard -rw- weinberger wrote at 19:00:35
> > Can you bisect the issue?
Is this bug fully reproducable? If not, then you may have had a git
bisect good, when it should have been git bisect bad.
The futex/plist should not be affecting rwsem.
-- Steve
>
> tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
> 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
> commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
> Author: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Wed Dec 22 14:18:50 2010 +0800
>
> futex,plist: Pass the real head of the priority list to plist_del()
>
> Some plist_del()s in kernel/futex.c are passed a faked head of the
> priority list.
>
> It does not fail because the current code does not require the real head
> in plist_del(). The current code of plist_del() just uses the head for
> checking,
> so it will not cause a bad result even when we use a faked head.
>
> But it is undocumented usage:
>
> /**
> * plist_del - Remove a @node from plist.
> *
> * @node: &struct plist_node pointer - entry to be removed
> * @head: &struct plist_head pointer - list head
> */
>
> The document says that the @head is the "list head" head of the priority
> list.
>
> In futex code, several places use "plist_del(&q->list, &q->list.plist);",
> they pass a fake head. We need to fix them all.
>
> Thanks to Darren Hart for many suggestions.
>
> Acked-by: Darren Hart <dvhart@linux.intel.com>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
> :040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
> ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
>
> --
> MfG/Sincerely
> Toralf Förster
> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-19 20:43 ` Steven Rostedt
0 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-19 20:43 UTC (permalink / raw)
To: Toralf Förster; +Cc: richard -rw- weinberger, LKML, user-mode-linux-devel
On Thu, May 19, 2011 at 10:18:16PM +0200, Toralf Förster wrote:
>
> richard -rw- weinberger wrote at 19:00:35
> > Can you bisect the issue?
Is this bug fully reproducable? If not, then you may have had a git
bisect good, when it should have been git bisect bad.
The futex/plist should not be affecting rwsem.
-- Steve
>
> tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
> 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
> commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
> Author: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Wed Dec 22 14:18:50 2010 +0800
>
> futex,plist: Pass the real head of the priority list to plist_del()
>
> Some plist_del()s in kernel/futex.c are passed a faked head of the
> priority list.
>
> It does not fail because the current code does not require the real head
> in plist_del(). The current code of plist_del() just uses the head for
> checking,
> so it will not cause a bad result even when we use a faked head.
>
> But it is undocumented usage:
>
> /**
> * plist_del - Remove a @node from plist.
> *
> * @node: &struct plist_node pointer - entry to be removed
> * @head: &struct plist_head pointer - list head
> */
>
> The document says that the @head is the "list head" head of the priority
> list.
>
> In futex code, several places use "plist_del(&q->list, &q->list.plist);",
> they pass a fake head. We need to fix them all.
>
> Thanks to Darren Hart for many suggestions.
>
> Acked-by: Darren Hart <dvhart@linux.intel.com>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
> :040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
> ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
>
> --
> MfG/Sincerely
> Toralf Förster
> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 16:34 ` Toralf Förster
@ 2011-05-20 6:44 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 6:44 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
Hi,
a few more questions/ideas. :)
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> FWIW I got :
>
> * Starting local
What is this "Starting local",
was UML crashing while starting your distro?
> Kernel panic - not syncing: Segfault with no mm
> 08335ed4: [<082b0b3b>] dump_stack+0x22/0x24
> 08335eec: [<082b0ba0>] panic+0x63/0x167
> 08335f14: [<080614af>] segv+0x27f/0x2f0
> 08335fcc: [<08061561>] segv_handler+0x41/0x60
> 08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
>
>
> EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
> Not tainted
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
> 08335e88: [<0807935d>] show_regs+0xed/0x120
> 08335ea4: [<0806179c>] panic_exit+0x2c/0x50
> 08335eb4: [<080a2b9c>] notifier_call_chain+0x4c/0x70
> 08335edc: [<080a2c13>] atomic_notifier_call_chain+0x23/0x30
> 08335eec: [<082b0bc8>] panic+0x8b/0x167
> 08335f14: [<080614af>] segv+0x27f/0x2f0
> 08335fcc: [<08061561>] segv_handler+0x41/0x60
> 08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
>
>
> and gdb gives in another session to reproduce the bug this:
>
> (gdb) c
> Continuing.
GDB stopped here and UML got SIGSEGV after you continued?
GDB has to ignore SIGSEGV. UML uses this signal to handle page faults.
type: handle SIGSEGV noprint nostop pass
I fear the backtrace is garbage.
Can you reproduce the issue using the default config?
Are you using hostfs?
What exactly is the output when it crashes? (Without GDB)
Your host's kernel ring buffer should contain a line like this one
after the crash:
linux[123]: segfault at 0 ip xxx sp xxx error 4 in linux[xxx+yyy]
Please share this line with me.
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 6:44 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 6:44 UTC (permalink / raw)
To: Toralf Förster; +Cc: LKML, user-mode-linux-devel
Hi,
a few more questions/ideas. :)
2011/5/19 Toralf Förster <toralf.foerster@gmx.de>:
> FWIW I got :
>
> * Starting local
What is this "Starting local",
was UML crashing while starting your distro?
> Kernel panic - not syncing: Segfault with no mm
> 08335ed4: [<082b0b3b>] dump_stack+0x22/0x24
> 08335eec: [<082b0ba0>] panic+0x63/0x167
> 08335f14: [<080614af>] segv+0x27f/0x2f0
> 08335fcc: [<08061561>] segv_handler+0x41/0x60
> 08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
>
>
> EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
> Not tainted
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
> 08335e88: [<0807935d>] show_regs+0xed/0x120
> 08335ea4: [<0806179c>] panic_exit+0x2c/0x50
> 08335eb4: [<080a2b9c>] notifier_call_chain+0x4c/0x70
> 08335edc: [<080a2c13>] atomic_notifier_call_chain+0x23/0x30
> 08335eec: [<082b0bc8>] panic+0x8b/0x167
> 08335f14: [<080614af>] segv+0x27f/0x2f0
> 08335fcc: [<08061561>] segv_handler+0x41/0x60
> 08335fec: [<08071da4>] sig_handler_common+0x44/0xb0
>
>
> and gdb gives in another session to reproduce the bug this:
>
> (gdb) c
> Continuing.
GDB stopped here and UML got SIGSEGV after you continued?
GDB has to ignore SIGSEGV. UML uses this signal to handle page faults.
type: handle SIGSEGV noprint nostop pass
I fear the backtrace is garbage.
Can you reproduce the issue using the default config?
Are you using hostfs?
What exactly is the output when it crashes? (Without GDB)
Your host's kernel ring buffer should contain a line like this one
after the crash:
linux[123]: segfault at 0 ip xxx sp xxx error 4 in linux[xxx+yyy]
Please share this line with me.
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-19 20:43 ` Steven Rostedt
@ 2011-05-20 7:37 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 7:37 UTC (permalink / raw)
To: Steven Rostedt; +Cc: richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 22:43:43
> Is this bug fully reproducable? If not, then you may have had a git
> bisect good, when it should have been git bisect bad.
Yes, bisected it again to the same commit.
Furthermore I explicitely checked out that revision - tested it - issue exists,
reverted exactly that commit on top of the checked out tree and tested it
again, issue went away.
Then I recompiled the buggy version with CONFIG_DEBUG_INFO=y
here's the output :
...
Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
08324b44: [<0829e78b>] dump_stack+0x22/0x24
08324b5c: [<0829e7f0>] panic+0x63/0x167
08324b84: [<080603d2>] segv+0x1e2/0x2b0
08324c3c: [<080604e1>] segv_handler+0x41/0x60
08324c5c: [<08070c54>] sig_handler_common+0x44/0xb0
08324cd8: [<08070e32>] sig_handler+0x42/0x50
08324ce8: [<0807106c>] handle_signal+0x5c/0xa0
08324d0c: [<08073408>] hard_handler+0x18/0x20
08324d1c: [<b7715400>] 0xb7715400
EIP: 0073:[<400008d2>] CPU: 0 Tainted: G W ESP: 007b:4ef22270 EFLAGS: 00200206
Tainted: G W
EAX: ffffffda EBX: 081efe10 ECX: 00000081 EDX: 00000001
ESI: 083f6758 EDI: 081efe0c EBP: 080a88a8 DS: 007b ES: 007b
08324af8: [<080780bd>] show_regs+0xed/0x120
08324b14: [<0806071c>] panic_exit+0x2c/0x50
08324b24: [<0809fc1c>] notifier_call_chain+0x4c/0x70
08324b4c: [<0809fc93>] atomic_notifier_call_chain+0x23/0x30
08324b5c: [<0829e818>] panic+0x8b/0x167
08324b84: [<080603d2>] segv+0x1e2/0x2b0
08324c3c: [<080604e1>] segv_handler+0x41/0x60
08324c5c: [<08070c54>] sig_handler_common+0x44/0xb0
08324cd8: [<08070e32>] sig_handler+0x42/0x50
08324ce8: [<0807106c>] handle_signal+0x5c/0xa0
08324d0c: [<08073408>] hard_handler+0x18/0x20
08324d1c: [<b7715400>] 0xb7715400
The file /var/log/messages of the UML says :
2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bda4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5be08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5be60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5be8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5beb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bfe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bffc: [<00000000>] 0x0
2011-05-20T09:33:03.457+02:00 n22_uml kernel:
2011-05-20T09:33:03.457+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473e8 ]---
2011-05-20T09:33:03.831+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.831+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99da4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99e08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99e60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99e8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99eb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99fe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99ffc: [<00000000>] 0x0
2011-05-20T09:33:03.832+02:00 n22_uml kernel:
2011-05-20T09:33:03.832+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473e9 ]---
2011-05-20T09:33:03.951+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.951+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bd78: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bd90: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bdb8: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bdc8: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bde0: [<080ab702>] futex_requeue+0x362/0x6b0
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5be64: [<080abceb>] do_futex+0x29b/0x6c0
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bec8: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bf20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bf68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bfe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bffc: [<00000000>] 0x0
2011-05-20T09:33:03.955+02:00 n22_uml kernel:
2011-05-20T09:33:03.955+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473ea ]---
2011-05-20T09:33:04.000+02:00 n22_uml sshd[738]: Server listening on 0.0.0.0 port 22.
2011-05-20T09:33:06.100+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:06.100+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0da4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0e08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0e60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0e8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0eb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0fe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0ffc: [<00000000>] 0x0
2011-05-20T09:33:06.104+02:00 n22_uml kernel:
2011-05-20T09:33:06.104+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473eb ]---
2011-05-20T09:33:09.000+02:00 n22_uml cron[851]: (CRON) STARTUP (V5.0)
2011-05-20T09:33:10.112+02:00 n22_uml kernel: Virtual console 1 assigned device '/dev/pts/5'
>
> The futex/plist should not be affecting rwsem.
>
> -- Steve
>
> > tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
> > 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
> > commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
> > Author: Lai Jiangshan <laijs@cn.fujitsu.com>
> > Date: Wed Dec 22 14:18:50 2010 +0800
> >
> > futex,plist: Pass the real head of the priority list to plist_del()
> >
> > Some plist_del()s in kernel/futex.c are passed a faked head of the
> > priority list.
> >
> > It does not fail because the current code does not require the real
> > head in plist_del(). The current code of plist_del() just uses the
> > head for
> >
> > checking,
> >
> > so it will not cause a bad result even when we use a faked head.
> >
> > But it is undocumented usage:
> >
> > /**
> >
> > * plist_del - Remove a @node from plist.
> > *
> > * @node: &struct plist_node pointer - entry to be removed
> > * @head: &struct plist_head pointer - list head
> > */
> >
> > The document says that the @head is the "list head" head of the
> > priority
> >
> > list.
> >
> > In futex code, several places use "plist_del(&q->list,
> > &q->list.plist);", they pass a fake head. We need to fix them all.
> >
> > Thanks to Darren Hart for many suggestions.
> >
> > Acked-by: Darren Hart <dvhart@linux.intel.com>
> > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > :
> > :040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
> >
> > ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 7:37 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 7:37 UTC (permalink / raw)
To: Steven Rostedt; +Cc: richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 22:43:43
> Is this bug fully reproducable? If not, then you may have had a git
> bisect good, when it should have been git bisect bad.
Yes, bisected it again to the same commit.
Furthermore I explicitely checked out that revision - tested it - issue exists,
reverted exactly that commit on top of the checked out tree and tested it
again, issue went away.
Then I recompiled the buggy version with CONFIG_DEBUG_INFO=y
here's the output :
...
Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
08324b44: [<0829e78b>] dump_stack+0x22/0x24
08324b5c: [<0829e7f0>] panic+0x63/0x167
08324b84: [<080603d2>] segv+0x1e2/0x2b0
08324c3c: [<080604e1>] segv_handler+0x41/0x60
08324c5c: [<08070c54>] sig_handler_common+0x44/0xb0
08324cd8: [<08070e32>] sig_handler+0x42/0x50
08324ce8: [<0807106c>] handle_signal+0x5c/0xa0
08324d0c: [<08073408>] hard_handler+0x18/0x20
08324d1c: [<b7715400>] 0xb7715400
EIP: 0073:[<400008d2>] CPU: 0 Tainted: G W ESP: 007b:4ef22270 EFLAGS: 00200206
Tainted: G W
EAX: ffffffda EBX: 081efe10 ECX: 00000081 EDX: 00000001
ESI: 083f6758 EDI: 081efe0c EBP: 080a88a8 DS: 007b ES: 007b
08324af8: [<080780bd>] show_regs+0xed/0x120
08324b14: [<0806071c>] panic_exit+0x2c/0x50
08324b24: [<0809fc1c>] notifier_call_chain+0x4c/0x70
08324b4c: [<0809fc93>] atomic_notifier_call_chain+0x23/0x30
08324b5c: [<0829e818>] panic+0x8b/0x167
08324b84: [<080603d2>] segv+0x1e2/0x2b0
08324c3c: [<080604e1>] segv_handler+0x41/0x60
08324c5c: [<08070c54>] sig_handler_common+0x44/0xb0
08324cd8: [<08070e32>] sig_handler+0x42/0x50
08324ce8: [<0807106c>] handle_signal+0x5c/0xa0
08324d0c: [<08073408>] hard_handler+0x18/0x20
08324d1c: [<b7715400>] 0xb7715400
The file /var/log/messages of the UML says :
2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bd7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5bda4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5be08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.455+02:00 n22_uml kernel: 19e5be60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5be8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5beb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bf68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bfe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.457+02:00 n22_uml kernel: 19e5bffc: [<00000000>] 0x0
2011-05-20T09:33:03.457+02:00 n22_uml kernel:
2011-05-20T09:33:03.457+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473e8 ]---
2011-05-20T09:33:03.831+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.831+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99d7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99da4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99e08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.831+02:00 n22_uml kernel: 19d99e60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99e8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99eb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99f68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99fe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.832+02:00 n22_uml kernel: 19d99ffc: [<00000000>] 0x0
2011-05-20T09:33:03.832+02:00 n22_uml kernel:
2011-05-20T09:33:03.832+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473e9 ]---
2011-05-20T09:33:03.951+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:03.951+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bd78: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bd90: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bdb8: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bdc8: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bde0: [<080ab702>] futex_requeue+0x362/0x6b0
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5be64: [<080abceb>] do_futex+0x29b/0x6c0
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bec8: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:03.951+02:00 n22_uml kernel: 19e5bf20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bf68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bfe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:03.955+02:00 n22_uml kernel: 19e5bffc: [<00000000>] 0x0
2011-05-20T09:33:03.955+02:00 n22_uml kernel:
2011-05-20T09:33:03.955+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473ea ]---
2011-05-20T09:33:04.000+02:00 n22_uml sshd[738]: Server listening on 0.0.0.0 port 22.
2011-05-20T09:33:06.100+02:00 n22_uml kernel: ------------[ cut here ]------------
2011-05-20T09:33:06.100+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d14: [<0829e78b>] dump_stack+0x22/0x24
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d2c: [<0808205a>] warn_slowpath_common+0x5a/0x80
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d54: [<080820a3>] warn_slowpath_null+0x23/0x30
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d64: [<080a9eb8>] wake_futex+0x28/0x60
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0d7c: [<080a9faf>] futex_wake+0xbf/0x100
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0da4: [<080abb1d>] do_futex+0xcd/0x6c0
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0e08: [<080ac184>] sys_futex+0x74/0x140
2011-05-20T09:33:06.100+02:00 n22_uml kernel: 19ef0e60: [<0807ffc1>] mm_release+0xd1/0x130
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0e8c: [<08083dad>] exit_mm+0x1d/0x100
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0eb8: [<08085b73>] do_exit+0xc3/0x660
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f14: [<080861e9>] sys_exit+0x19/0x20
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f20: [<08060d16>] handle_syscall+0xa6/0xb0
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0f68: [<08074cf1>] userspace+0x361/0x500
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0fe8: [<0805e0cb>] fork_handler+0x5b/0x70
2011-05-20T09:33:06.104+02:00 n22_uml kernel: 19ef0ffc: [<00000000>] 0x0
2011-05-20T09:33:06.104+02:00 n22_uml kernel:
2011-05-20T09:33:06.104+02:00 n22_uml kernel: ---[ end trace 95fb08f635a473eb ]---
2011-05-20T09:33:09.000+02:00 n22_uml cron[851]: (CRON) STARTUP (V5.0)
2011-05-20T09:33:10.112+02:00 n22_uml kernel: Virtual console 1 assigned device '/dev/pts/5'
>
> The futex/plist should not be affecting rwsem.
>
> -- Steve
>
> > tfoerste@n22 ~/devel/linux-2.6 $ git bisect bad
> > 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c is the first bad commit
> > commit 2e12978a9f7a7abd54e8eb9ce70a7718767b8b2c
> > Author: Lai Jiangshan <laijs@cn.fujitsu.com>
> > Date: Wed Dec 22 14:18:50 2010 +0800
> >
> > futex,plist: Pass the real head of the priority list to plist_del()
> >
> > Some plist_del()s in kernel/futex.c are passed a faked head of the
> > priority list.
> >
> > It does not fail because the current code does not require the real
> > head in plist_del(). The current code of plist_del() just uses the
> > head for
> >
> > checking,
> >
> > so it will not cause a bad result even when we use a faked head.
> >
> > But it is undocumented usage:
> >
> > /**
> >
> > * plist_del - Remove a @node from plist.
> > *
> > * @node: &struct plist_node pointer - entry to be removed
> > * @head: &struct plist_head pointer - list head
> > */
> >
> > The document says that the @head is the "list head" head of the
> > priority
> >
> > list.
> >
> > In futex code, several places use "plist_del(&q->list,
> > &q->list.plist);", they pass a fake head. We need to fix them all.
> >
> > Thanks to Darren Hart for many suggestions.
> >
> > Acked-by: Darren Hart <dvhart@linux.intel.com>
> > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > LKML-Reference: <4D11984A.5030203@cn.fujitsu.com>
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > :
> > :040000 040000 78d47de377f8da1c131007a17ca915fbd13f7ff6
> >
> > ffac93205aaf22fda0667d6395c8da7c7bf692e4 M kernel
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 6:44 ` richard -rw- weinberger
@ 2011-05-20 7:43 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 7:43 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 08:44:39
> > * Starting local
>
> What is this "Starting local",
> was UML crashing while starting your distro?
No, that the last init script of the Gentoo, I'm using within UML.
> I fear the backtrace is garbage.
yep, maybe this helps more :
Program received signal SIGSEGV, Segmentation fault.
0x080a9f6b in futex_wake (uaddr=<value optimized out>, flags=<value optimized out>, nr_wake=<value optimized out>,
bitset=4294967295) at kernel/futex.c:958
958 plist_for_each_entry_safe(this, next, head, list) {
(gdb) bt
#0 0x080a9f6b in futex_wake (uaddr=<value optimized out>, flags=<value optimized out>, nr_wake=<value optimized out>,
bitset=4294967295) at kernel/futex.c:958
#1 0x080abb1d in do_futex (uaddr=0x81efe10, op=0, val=0, timeout=0x0, uaddr2=0x81efe0c, val2=0, val3=4294967295)
at kernel/futex.c:2610
#2 0x080ac184 in sys_futex (uaddr=0x81efe10, op=129, val=1, utime=0x83f89b8, uaddr2=0x81efe0c, val3=134908072)
at kernel/futex.c:2678
#3 0x08060d16 in handle_syscall (r=0x19545290) at arch/um/kernel/skas/syscall.c:35
#4 0x08074cf1 in handle_trap (regs=0x19545290) at arch/um/os-Linux/skas/process.c:201
#5 userspace (regs=0x19545290) at arch/um/os-Linux/skas/process.c:417
#6 0x0805e0cb in fork_handler () at arch/um/kernel/process.c:181
#7 0x00000000 in ?? ()
>
> Can you reproduce the issue using the default config?
yes
> Are you using hostfs?
Yes, but the issue is independend from that.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 7:43 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 7:43 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 08:44:39
> > * Starting local
>
> What is this "Starting local",
> was UML crashing while starting your distro?
No, that the last init script of the Gentoo, I'm using within UML.
> I fear the backtrace is garbage.
yep, maybe this helps more :
Program received signal SIGSEGV, Segmentation fault.
0x080a9f6b in futex_wake (uaddr=<value optimized out>, flags=<value optimized out>, nr_wake=<value optimized out>,
bitset=4294967295) at kernel/futex.c:958
958 plist_for_each_entry_safe(this, next, head, list) {
(gdb) bt
#0 0x080a9f6b in futex_wake (uaddr=<value optimized out>, flags=<value optimized out>, nr_wake=<value optimized out>,
bitset=4294967295) at kernel/futex.c:958
#1 0x080abb1d in do_futex (uaddr=0x81efe10, op=0, val=0, timeout=0x0, uaddr2=0x81efe0c, val2=0, val3=4294967295)
at kernel/futex.c:2610
#2 0x080ac184 in sys_futex (uaddr=0x81efe10, op=129, val=1, utime=0x83f89b8, uaddr2=0x81efe0c, val3=134908072)
at kernel/futex.c:2678
#3 0x08060d16 in handle_syscall (r=0x19545290) at arch/um/kernel/skas/syscall.c:35
#4 0x08074cf1 in handle_trap (regs=0x19545290) at arch/um/os-Linux/skas/process.c:201
#5 userspace (regs=0x19545290) at arch/um/os-Linux/skas/process.c:417
#6 0x0805e0cb in fork_handler () at arch/um/kernel/process.c:181
#7 0x00000000 in ?? ()
>
> Can you reproduce the issue using the default config?
yes
> Are you using hostfs?
Yes, but the issue is independend from that.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 7:37 ` Toralf Förster
@ 2011-05-20 7:56 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 7:56 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> ...
> Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
Looks like a NULL-pointer bug.
What code is at address 80a9f6b?
Use "objdump -d -S | less" to find it.
Please note, kernel binary and log message have to match!
> The file /var/log/messages of the UML says :
>
> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
Is this really 2.6.39?
Line 789 contains no WARN*().
http://lxr.linux.no/#linux+v2.6.39/kernel/futex.c#L789
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 7:56 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 7:56 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> ...
> Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
Looks like a NULL-pointer bug.
What code is at address 80a9f6b?
Use "objdump -d -S | less" to find it.
Please note, kernel binary and log message have to match!
> The file /var/log/messages of the UML says :
>
> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
Is this really 2.6.39?
Line 789 contains no WARN*().
http://lxr.linux.no/#linux+v2.6.39/kernel/futex.c#L789
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 7:56 ` richard -rw- weinberger
(?)
@ 2011-05-20 8:39 ` richard -rw- weinberger
2011-05-20 8:58 ` Toralf Förster
-1 siblings, 1 reply; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 8:39 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 richard -rw- weinberger <richard.weinberger@gmail.com>:
> Use "objdump -d -S | less" to find it.
Ick, I meant "objdump -d -S vmlinux | less"
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 7:56 ` richard -rw- weinberger
@ 2011-05-20 8:42 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 8:42 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 09:56:02
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> > ...
> > Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>
> Looks like a NULL-pointer bug.
> What code is at address 80a9f6b?
> Use "objdump -d -S | less" to find it.
if (unlikely(ret != 0))
80a9f3a: 85 c0 test %eax,%eax
80a9f3c: 75 ca jne 80a9f08 <futex_wake+0x18>
goto out;
hb = hash_futex(&key);
80a9f3e: 8d 45 e8 lea -0x18(%ebp),%eax
80a9f41: e8 aa f6 ff ff call 80a95f0 <hash_futex>
80a9f46: 89 c2 mov %eax,%edx
spin_lock(&hb->lock);
head = &hb->chain;
plist_for_each_entry_safe(this, next, head, list) {
80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
80a9f4b: 83 c2 08 add $0x8,%edx
80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
80a9f51: 39 ca cmp %ecx,%edx
80a9f53: 8b 70 0c mov 0xc(%eax),%esi
80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
80a9f58: 89 d9 mov %ebx,%ecx
80a9f5a: 83 ee 0c sub $0xc,%esi
80a9f5d: 89 d3 mov %edx,%ebx
80a9f5f: 89 fa mov %edi,%edx
80a9f61: 89 cf mov %ecx,%edi
80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
80a9f65: 8d 76 00 lea 0x0(%esi),%esi
80a9f68: 8d 46 0c lea 0xc(%esi),%eax
80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
80a9f6e: 39 c3 cmp %eax,%ebx
80a9f70: 74 4e je 80a9fc0 <futex_wake+0xd0>
80a9f72: 89 f0 mov %esi,%eax
80a9f74: 8d 71 f4 lea -0xc(%ecx),%esi
if (match_futex (&this->key, &key)) {
80a9f77: 83 f8 e4 cmp $0xffffffe4,%eax
80a9f7a: 74 ec je 80a9f68 <futex_wake+0x78>
80a9f7c: 8b 48 1c mov 0x1c(%eax),%ecx
80a9f7f: 3b 4d e8 cmp -0x18(%ebp),%ecx
80a9f82: 75 e4 jne 80a9f68 <futex_wake+0x78>
/*
* Return 1 if two futex_keys are equal, 0 otherwise.
*/
> Is this really 2.6.39?
No, but I didn't want to change the subject line, the bisected version is :
v2.6.38-rc8-1-g2e12978
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 8:42 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 8:42 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 09:56:02
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> > ...
> > Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>
> Looks like a NULL-pointer bug.
> What code is at address 80a9f6b?
> Use "objdump -d -S | less" to find it.
if (unlikely(ret != 0))
80a9f3a: 85 c0 test %eax,%eax
80a9f3c: 75 ca jne 80a9f08 <futex_wake+0x18>
goto out;
hb = hash_futex(&key);
80a9f3e: 8d 45 e8 lea -0x18(%ebp),%eax
80a9f41: e8 aa f6 ff ff call 80a95f0 <hash_futex>
80a9f46: 89 c2 mov %eax,%edx
spin_lock(&hb->lock);
head = &hb->chain;
plist_for_each_entry_safe(this, next, head, list) {
80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
80a9f4b: 83 c2 08 add $0x8,%edx
80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
80a9f51: 39 ca cmp %ecx,%edx
80a9f53: 8b 70 0c mov 0xc(%eax),%esi
80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
80a9f58: 89 d9 mov %ebx,%ecx
80a9f5a: 83 ee 0c sub $0xc,%esi
80a9f5d: 89 d3 mov %edx,%ebx
80a9f5f: 89 fa mov %edi,%edx
80a9f61: 89 cf mov %ecx,%edi
80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
80a9f65: 8d 76 00 lea 0x0(%esi),%esi
80a9f68: 8d 46 0c lea 0xc(%esi),%eax
80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
80a9f6e: 39 c3 cmp %eax,%ebx
80a9f70: 74 4e je 80a9fc0 <futex_wake+0xd0>
80a9f72: 89 f0 mov %esi,%eax
80a9f74: 8d 71 f4 lea -0xc(%ecx),%esi
if (match_futex (&this->key, &key)) {
80a9f77: 83 f8 e4 cmp $0xffffffe4,%eax
80a9f7a: 74 ec je 80a9f68 <futex_wake+0x78>
80a9f7c: 8b 48 1c mov 0x1c(%eax),%ecx
80a9f7f: 3b 4d e8 cmp -0x18(%ebp),%ecx
80a9f82: 75 e4 jne 80a9f68 <futex_wake+0x78>
/*
* Return 1 if two futex_keys are equal, 0 otherwise.
*/
> Is this really 2.6.39?
No, but I didn't want to change the subject line, the bisected version is :
v2.6.38-rc8-1-g2e12978
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 8:39 ` richard -rw- weinberger
@ 2011-05-20 8:58 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 8:58 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 10:39:03
> 2011/5/20 richard -rw- weinberger <richard.weinberger@gmail.com>:
> > Use "objdump -d -S | less" to find it.
>
> Ick, I meant "objdump -d -S vmlinux | less"
Well (BTW nearly similar to the result of "objdump -d -S linux" ), but anyway
here it is :
spin_lock(&hb->lock);
head = &hb->chain;
plist_for_each_entry_safe(this, next, head, list) {
80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
80a9f4b: 83 c2 08 add $0x8,%edx
80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
80a9f51: 39 ca cmp %ecx,%edx
80a9f53: 8b 70 0c mov 0xc(%eax),%esi
80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
80a9f58: 89 d9 mov %ebx,%ecx
80a9f5a: 83 ee 0c sub $0xc,%esi
80a9f5d: 89 d3 mov %edx,%ebx
80a9f5f: 89 fa mov %edi,%edx
80a9f61: 89 cf mov %ecx,%edi
80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
80a9f65: 8d 76 00 lea 0x0(%esi),%esi
80a9f68: 8d 46 0c lea 0xc(%esi),%eax
80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
80a9f6e: 39 c3 cmp %eax,%ebx
80a9f70: 74 4e je 80a9fc0 <futex_wake+0xd0>
80a9f72: 89 f0 mov %esi,%eax
80a9f74: 8d 71 f4 lea -0xc(%ecx),%esi
if (match_futex (&this->key, &key)) {
80a9f77: 83 f8 e4 cmp $0xffffffe4,%eax
80a9f7a: 74 ec je 80a9f68 <futex_wake+0x78>
80a9f7c: 8b 48 1c mov 0x1c(%eax),%ecx
80a9f7f: 3b 4d e8 cmp -0x18(%ebp),%ecx
80a9f82: 75 e4 jne 80a9f68 <futex_wake+0x78>
/*
* Return 1 if two futex_keys are equal, 0 otherwise.
*/
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 8:58 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 8:58 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 10:39:03
> 2011/5/20 richard -rw- weinberger <richard.weinberger@gmail.com>:
> > Use "objdump -d -S | less" to find it.
>
> Ick, I meant "objdump -d -S vmlinux | less"
Well (BTW nearly similar to the result of "objdump -d -S linux" ), but anyway
here it is :
spin_lock(&hb->lock);
head = &hb->chain;
plist_for_each_entry_safe(this, next, head, list) {
80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
80a9f4b: 83 c2 08 add $0x8,%edx
80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
80a9f51: 39 ca cmp %ecx,%edx
80a9f53: 8b 70 0c mov 0xc(%eax),%esi
80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
80a9f58: 89 d9 mov %ebx,%ecx
80a9f5a: 83 ee 0c sub $0xc,%esi
80a9f5d: 89 d3 mov %edx,%ebx
80a9f5f: 89 fa mov %edi,%edx
80a9f61: 89 cf mov %ecx,%edi
80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
80a9f65: 8d 76 00 lea 0x0(%esi),%esi
80a9f68: 8d 46 0c lea 0xc(%esi),%eax
80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
80a9f6e: 39 c3 cmp %eax,%ebx
80a9f70: 74 4e je 80a9fc0 <futex_wake+0xd0>
80a9f72: 89 f0 mov %esi,%eax
80a9f74: 8d 71 f4 lea -0xc(%ecx),%esi
if (match_futex (&this->key, &key)) {
80a9f77: 83 f8 e4 cmp $0xffffffe4,%eax
80a9f7a: 74 ec je 80a9f68 <futex_wake+0x78>
80a9f7c: 8b 48 1c mov 0x1c(%eax),%ecx
80a9f7f: 3b 4d e8 cmp -0x18(%ebp),%ecx
80a9f82: 75 e4 jne 80a9f68 <futex_wake+0x78>
/*
* Return 1 if two futex_keys are equal, 0 otherwise.
*/
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 8:58 ` Toralf Förster
@ 2011-05-20 9:02 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 9:02 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> Ick, I meant "objdump -d -S vmlinux | less"
> Well (BTW nearly similar to the result of "objdump -d -S linux" ), but anyway
> here it is :
I hope it's _exactly_ the same result. vmlinux and linux are hard linked...
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 9:02 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 9:02 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> Ick, I meant "objdump -d -S vmlinux | less"
> Well (BTW nearly similar to the result of "objdump -d -S linux" ), but anyway
> here it is :
I hope it's _exactly_ the same result. vmlinux and linux are hard linked...
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 9:02 ` richard -rw- weinberger
@ 2011-05-20 9:19 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 9:19 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 11:02:35
> I hope it's _exactly_ the same result. vmlinux and linux are hard linked...
tfoerste@n22 ~/devel/linux-2.6 $ ls -lid vmlinux linux
2034205 -rwxr-xr-x 2 tfoerste users 35624874 May 20 09:28 linux
2034205 -rwxr-xr-x 2 tfoerste users 35624874 May 20 09:28 vmlinux
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 9:19 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 9:19 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 11:02:35
> I hope it's _exactly_ the same result. vmlinux and linux are hard linked...
tfoerste@n22 ~/devel/linux-2.6 $ ls -lid vmlinux linux
2034205 -rwxr-xr-x 2 tfoerste users 35624874 May 20 09:28 linux
2034205 -rwxr-xr-x 2 tfoerste users 35624874 May 20 09:28 vmlinux
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 7:56 ` richard -rw- weinberger
@ 2011-05-20 15:55 ` Darren Hart
-1 siblings, 0 replies; 58+ messages in thread
From: Darren Hart @ 2011-05-20 15:55 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Toralf Förster, Steven Rostedt, LKML, user-mode-linux-devel
On 05/20/2011 12:56 AM, richard -rw- weinberger wrote:
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> ...
>> Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>
> Looks like a NULL-pointer bug.
> What code is at address 80a9f6b?
> Use "objdump -d -S | less" to find it.
> Please note, kernel binary and log message have to match!
>
>> The file /var/log/messages of the UML says :
>>
>> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
>> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
>
> Is this really 2.6.39?
> Line 789 contains no WARN*().
> http://lxr.linux.no/#linux+v2.6.39/kernel/futex.c#L789
>
I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
|| plist_node_empty(&q->list)))
Toralf, can you instrument that let us know which of conditions is
triggering the WARN_ON? Something like the following should be adequate
to get you the line number. I suspect it is plist_node_empty give the
git bisect results you reported.
diff --git a/kernel/futex.c b/kernel/futex.c
index abd5324..7f31bca 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
{
struct futex_hash_bucket *hb;
- if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
- || plist_node_empty(&q->list)))
+ if (WARN_ON(!q->lock_ptr))
+ return;
+ if (!spin_is_locked(q->lock_ptr))
+ return;
+ if (plist_node_empty(&q->list))
return;
hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 15:55 ` Darren Hart
0 siblings, 0 replies; 58+ messages in thread
From: Darren Hart @ 2011-05-20 15:55 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Toralf Förster, Steven Rostedt, LKML, user-mode-linux-devel
On 05/20/2011 12:56 AM, richard -rw- weinberger wrote:
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> ...
>> Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>
> Looks like a NULL-pointer bug.
> What code is at address 80a9f6b?
> Use "objdump -d -S | less" to find it.
> Please note, kernel binary and log message have to match!
>
>> The file /var/log/messages of the UML says :
>>
>> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: ------------[ cut here ]------------
>> 2011-05-20T09:33:03.455+02:00 n22_uml kernel: WARNING: at kernel/futex.c:789 wake_futex+0x28/0x60()
>
> Is this really 2.6.39?
> Line 789 contains no WARN*().
> http://lxr.linux.no/#linux+v2.6.39/kernel/futex.c#L789
>
I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
|| plist_node_empty(&q->list)))
Toralf, can you instrument that let us know which of conditions is
triggering the WARN_ON? Something like the following should be adequate
to get you the line number. I suspect it is plist_node_empty give the
git bisect results you reported.
diff --git a/kernel/futex.c b/kernel/futex.c
index abd5324..7f31bca 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
{
struct futex_hash_bucket *hb;
- if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
- || plist_node_empty(&q->list)))
+ if (WARN_ON(!q->lock_ptr))
+ return;
+ if (!spin_is_locked(q->lock_ptr))
+ return;
+ if (plist_node_empty(&q->list))
return;
hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 15:55 ` Darren Hart
(?)
@ 2011-05-20 16:04 ` Steven Rostedt
2011-05-20 16:11 ` Steven Rostedt
2011-05-20 17:35 ` Darren Hart
-1 siblings, 2 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 16:04 UTC (permalink / raw)
To: Darren Hart
Cc: richard -rw- weinberger, Toralf Förster, LKML,
user-mode-linux-devel
On Fri, 2011-05-20 at 08:55 -0700, Darren Hart wrote:
> I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
>
> if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> || plist_node_empty(&q->list)))
>
> Toralf, can you instrument that let us know which of conditions is
> triggering the WARN_ON? Something like the following should be adequate
> to get you the line number. I suspect it is plist_node_empty give the
> git bisect results you reported.
>
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index abd5324..7f31bca 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
> {
> struct futex_hash_bucket *hb;
>
> - if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> - || plist_node_empty(&q->list)))
> + if (WARN_ON(!q->lock_ptr))
> + return;
> + if (!spin_is_locked(q->lock_ptr))
> + return;
> + if (plist_node_empty(&q->list))
> return;
>
Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
I think UML is UP, and that spin_is_locked() will always return false.
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 16:04 ` Steven Rostedt
@ 2011-05-20 16:11 ` Steven Rostedt
2011-05-20 17:10 ` Toralf Förster
2011-05-20 22:53 ` Toralf Förster
2011-05-20 17:35 ` Darren Hart
1 sibling, 2 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 16:11 UTC (permalink / raw)
To: Darren Hart
Cc: richard -rw- weinberger, Toralf Förster, LKML,
user-mode-linux-devel
On Fri, 2011-05-20 at 12:04 -0400, Steven Rostedt wrote:
> On Fri, 2011-05-20 at 08:55 -0700, Darren Hart wrote:
>
> > I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
> >
> > if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> > || plist_node_empty(&q->list)))
> >
> > Toralf, can you instrument that let us know which of conditions is
> > triggering the WARN_ON? Something like the following should be adequate
> > to get you the line number. I suspect it is plist_node_empty give the
> > git bisect results you reported.
> >
> >
> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index abd5324..7f31bca 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
> > {
> > struct futex_hash_bucket *hb;
> >
> > - if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
> > - || plist_node_empty(&q->list)))
> > + if (WARN_ON(!q->lock_ptr))
> > + return;
> > + if (!spin_is_locked(q->lock_ptr))
> > + return;
> > + if (plist_node_empty(&q->list))
> > return;
> >
>
> Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
>
> I think UML is UP, and that spin_is_locked() will always return false.
>
Could you apply these patches:
2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
29096202 futex: Fix WARN_ON() test for UP
On top of this commit, and see if the problem goes away. What could have
happened, is that you have two bugs, with one of them fixed. If the git
bisect stumbled on this bug, it will show this one, even though later
on, this code was fixed. If you apply the above two patches and it works
again, then this isn't the bug you are looking for.
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 8:42 ` Toralf Förster
@ 2011-05-20 16:24 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 16:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>
> richard -rw- weinberger wrote at 09:56:02
>> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> > ...
>> > Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>>
>> Looks like a NULL-pointer bug.
>> What code is at address 80a9f6b?
>> Use "objdump -d -S | less" to find it.
> if (unlikely(ret != 0))
> 80a9f3a: 85 c0 test %eax,%eax
> 80a9f3c: 75 ca jne 80a9f08 <futex_wake+0x18>
> goto out;
>
> hb = hash_futex(&key);
> 80a9f3e: 8d 45 e8 lea -0x18(%ebp),%eax
> 80a9f41: e8 aa f6 ff ff call 80a95f0 <hash_futex>
> 80a9f46: 89 c2 mov %eax,%edx
> spin_lock(&hb->lock);
> head = &hb->chain;
>
> plist_for_each_entry_safe(this, next, head, list) {
> 80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
> 80a9f4b: 83 c2 08 add $0x8,%edx
> 80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
> 80a9f51: 39 ca cmp %ecx,%edx
> 80a9f53: 8b 70 0c mov 0xc(%eax),%esi
> 80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
> 80a9f58: 89 d9 mov %ebx,%ecx
> 80a9f5a: 83 ee 0c sub $0xc,%esi
> 80a9f5d: 89 d3 mov %edx,%ebx
> 80a9f5f: 89 fa mov %edi,%edx
> 80a9f61: 89 cf mov %ecx,%edi
> 80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
> 80a9f65: 8d 76 00 lea 0x0(%esi),%esi
> 80a9f68: 8d 46 0c lea 0xc(%esi),%eax
> 80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
Here in futex_wake() happens a NULL pointer dereference.
Steve, any ideas?
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 16:24 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-20 16:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: Steven Rostedt, LKML, user-mode-linux-devel
2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>
> richard -rw- weinberger wrote at 09:56:02
>> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
>> > ...
>> > Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x80a9f6b
>>
>> Looks like a NULL-pointer bug.
>> What code is at address 80a9f6b?
>> Use "objdump -d -S | less" to find it.
> if (unlikely(ret != 0))
> 80a9f3a: 85 c0 test %eax,%eax
> 80a9f3c: 75 ca jne 80a9f08 <futex_wake+0x18>
> goto out;
>
> hb = hash_futex(&key);
> 80a9f3e: 8d 45 e8 lea -0x18(%ebp),%eax
> 80a9f41: e8 aa f6 ff ff call 80a95f0 <hash_futex>
> 80a9f46: 89 c2 mov %eax,%edx
> spin_lock(&hb->lock);
> head = &hb->chain;
>
> plist_for_each_entry_safe(this, next, head, list) {
> 80a9f48: 8b 48 08 mov 0x8(%eax),%ecx
> 80a9f4b: 83 c2 08 add $0x8,%edx
> 80a9f4e: 8d 41 f4 lea -0xc(%ecx),%eax
> 80a9f51: 39 ca cmp %ecx,%edx
> 80a9f53: 8b 70 0c mov 0xc(%eax),%esi
> 80a9f56: 74 6a je 80a9fc2 <futex_wake+0xd2>
> 80a9f58: 89 d9 mov %ebx,%ecx
> 80a9f5a: 83 ee 0c sub $0xc,%esi
> 80a9f5d: 89 d3 mov %edx,%ebx
> 80a9f5f: 89 fa mov %edi,%edx
> 80a9f61: 89 cf mov %ecx,%edi
> 80a9f63: eb 12 jmp 80a9f77 <futex_wake+0x87>
> 80a9f65: 8d 76 00 lea 0x0(%esi),%esi
> 80a9f68: 8d 46 0c lea 0xc(%esi),%eax
> 80a9f6b: 8b 4e 0c mov 0xc(%esi),%ecx
Here in futex_wake() happens a NULL pointer dereference.
Steve, any ideas?
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 16:11 ` Steven Rostedt
@ 2011-05-20 17:10 ` Toralf Förster
2011-05-20 22:53 ` Toralf Förster
1 sibling, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 17:10 UTC (permalink / raw)
To: Steven Rostedt
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 18:11:36
> > Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
> >
> > I think UML is UP, and that spin_is_locked() will always return false.
>
> Could you apply these patches:
>
> 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> 29096202 futex: Fix WARN_ON() test for UP
>
> On top of this commit, and see if the problem goes away. What could have
> happened, is that you have two bugs, with one of them fixed. If the git
> bisect stumbled on this bug, it will show this one, even though later
> on, this code was fixed. If you apply the above two patches and it works
> again, then this isn't the bug you are looking for.
>
> -- Steve
Right - applying those 2 commits on top of v2.6.38-rc8-1-g2e12978 works - now
the issue is away.
And yes - now I've to look for the other of two bugs, which was introduced
between the tags v2.6.38 and v2.6.39, I think.
Is there's an easy way to check, whether a given checked out git tree contains
a specific commit id ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 17:10 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 17:10 UTC (permalink / raw)
To: Steven Rostedt
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 18:11:36
> > Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
> >
> > I think UML is UP, and that spin_is_locked() will always return false.
>
> Could you apply these patches:
>
> 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> 29096202 futex: Fix WARN_ON() test for UP
>
> On top of this commit, and see if the problem goes away. What could have
> happened, is that you have two bugs, with one of them fixed. If the git
> bisect stumbled on this bug, it will show this one, even though later
> on, this code was fixed. If you apply the above two patches and it works
> again, then this isn't the bug you are looking for.
>
> -- Steve
Right - applying those 2 commits on top of v2.6.38-rc8-1-g2e12978 works - now
the issue is away.
And yes - now I've to look for the other of two bugs, which was introduced
between the tags v2.6.38 and v2.6.39, I think.
Is there's an easy way to check, whether a given checked out git tree contains
a specific commit id ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 16:24 ` richard -rw- weinberger
@ 2011-05-20 17:19 ` Steven Rostedt
-1 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:19 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Toralf Förster, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 18:24 +0200, richard -rw- weinberger wrote:
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> >
> Here in futex_wake() happens a NULL pointer dereference.
> Steve, any ideas?
>
Yes, if this is from the bisect, and does not contain the two commits
that I've posted in another email. Without those fixes, the futex code
will error and return without doing the proper work and cause all sorts
of bugs.
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 17:19 ` Steven Rostedt
0 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:19 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Toralf Förster, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 18:24 +0200, richard -rw- weinberger wrote:
> 2011/5/20 Toralf Förster <toralf.foerster@gmx.de>:
> >
> Here in futex_wake() happens a NULL pointer dereference.
> Steve, any ideas?
>
Yes, if this is from the bisect, and does not contain the two commits
that I've posted in another email. Without those fixes, the futex code
will error and return without doing the proper work and cause all sorts
of bugs.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 16:04 ` Steven Rostedt
2011-05-20 16:11 ` Steven Rostedt
@ 2011-05-20 17:35 ` Darren Hart
2011-05-20 17:41 ` Steven Rostedt
1 sibling, 1 reply; 58+ messages in thread
From: Darren Hart @ 2011-05-20 17:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: richard -rw- weinberger, Toralf Förster, LKML,
user-mode-linux-devel
On 05/20/2011 09:04 AM, Steven Rostedt wrote:
> On Fri, 2011-05-20 at 08:55 -0700, Darren Hart wrote:
>
>> I suspect Toralf is hitting the WARN_ON in __unqueue_futex:
>>
>> if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
>> || plist_node_empty(&q->list)))
>>
>> Toralf, can you instrument that let us know which of conditions is
>> triggering the WARN_ON? Something like the following should be adequate
>> to get you the line number. I suspect it is plist_node_empty give the
>> git bisect results you reported.
>>
>>
>> diff --git a/kernel/futex.c b/kernel/futex.c
>> index abd5324..7f31bca 100644
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -782,8 +782,11 @@ static void __unqueue_futex(struct futex_q *q)
>> {
>> struct futex_hash_bucket *hb;
>>
>> - if (WARN_ON(!q->lock_ptr || !spin_is_locked(q->lock_ptr)
>> - || plist_node_empty(&q->list)))
>> + if (WARN_ON(!q->lock_ptr))
>> + return;
>> + if (!spin_is_locked(q->lock_ptr))
>> + return;
>> + if (plist_node_empty(&q->list))
>> return;
>>
>
Whoops, there should have been WARN_ON's in all the if blocks... duh.
> Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
Hrm, I thought he said he was on 2.6.39-rc-something. Those patches went
in pre 2.6.39-rc1 according to gitk.
>
> I think UML is UP, and that spin_is_locked() will always return false.
>
> -- Steve
>
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 17:35 ` Darren Hart
@ 2011-05-20 17:41 ` Steven Rostedt
0 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:41 UTC (permalink / raw)
To: Darren Hart
Cc: richard -rw- weinberger, Toralf Förster, LKML,
user-mode-linux-devel
On Fri, 2011-05-20 at 10:35 -0700, Darren Hart wrote:
> > Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
>
> Hrm, I thought he said he was on 2.6.39-rc-something. Those patches went
> in pre 2.6.39-rc1 according to gitk.
A git bisect can easily stumble on this where the fix is not made.
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 17:10 ` Toralf Förster
@ 2011-05-20 17:44 ` Steven Rostedt
-1 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:44 UTC (permalink / raw)
To: Toralf Förster
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 19:10 +0200, Toralf Förster wrote:
> Is there's an easy way to check, whether a given checked out git tree contains
> a specific commit id ?
You can try:
git log --pretty=oneline | grep <SHA1>
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 17:44 ` Steven Rostedt
0 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:44 UTC (permalink / raw)
To: Toralf Förster
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 19:10 +0200, Toralf Förster wrote:
> Is there's an easy way to check, whether a given checked out git tree contains
> a specific commit id ?
You can try:
git log --pretty=oneline | grep <SHA1>
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 17:10 ` Toralf Förster
@ 2011-05-20 17:46 ` Steven Rostedt
-1 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:46 UTC (permalink / raw)
To: Toralf Förster
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 19:10 +0200, Toralf Förster wrote:
> Steven Rostedt wrote at 18:11:36
> > > Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
> > >
> > > I think UML is UP, and that spin_is_locked() will always return false.
> >
> > Could you apply these patches:
> >
> > 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> > 29096202 futex: Fix WARN_ON() test for UP
> >
> > On top of this commit, and see if the problem goes away. What could have
> > happened, is that you have two bugs, with one of them fixed. If the git
> > bisect stumbled on this bug, it will show this one, even though later
> > on, this code was fixed. If you apply the above two patches and it works
> > again, then this isn't the bug you are looking for.
> >
> > -- Steve
> Right - applying those 2 commits on top of v2.6.38-rc8-1-g2e12978 works - now
> the issue is away.
>
> And yes - now I've to look for the other of two bugs, which was introduced
> between the tags v2.6.38 and v2.6.39, I think.
Another thing you could do is checkout 29096202 and see if it works. If
it does, you can base that as your "git bisect good" and you should not
be affected by this bug again.
-- Steve
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 17:46 ` Steven Rostedt
0 siblings, 0 replies; 58+ messages in thread
From: Steven Rostedt @ 2011-05-20 17:46 UTC (permalink / raw)
To: Toralf Förster
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
On Fri, 2011-05-20 at 19:10 +0200, Toralf Förster wrote:
> Steven Rostedt wrote at 18:11:36
> > > Wait! This is where we need the WARN_ON_SMP(), do we have that patch in?
> > >
> > > I think UML is UP, and that spin_is_locked() will always return false.
> >
> > Could you apply these patches:
> >
> > 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> > 29096202 futex: Fix WARN_ON() test for UP
> >
> > On top of this commit, and see if the problem goes away. What could have
> > happened, is that you have two bugs, with one of them fixed. If the git
> > bisect stumbled on this bug, it will show this one, even though later
> > on, this code was fixed. If you apply the above two patches and it works
> > again, then this isn't the bug you are looking for.
> >
> > -- Steve
> Right - applying those 2 commits on top of v2.6.38-rc8-1-g2e12978 works - now
> the issue is away.
>
> And yes - now I've to look for the other of two bugs, which was introduced
> between the tags v2.6.38 and v2.6.39, I think.
Another thing you could do is checkout 29096202 and see if it works. If
it does, you can base that as your "git bisect good" and you should not
be affected by this bug again.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 16:11 ` Steven Rostedt
@ 2011-05-20 22:53 ` Toralf Förster
2011-05-20 22:53 ` Toralf Förster
1 sibling, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 22:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 18:11:36
> Could you apply these patches:
>
> 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> 29096202 futex: Fix WARN_ON() test for UP
>
> On top of this commit, and see if the problem goes away. What could have
> happened, is that you have two bugs, with one of them fixed. If the git
> bisect stumbled on this bug, it will show this one, even though later
> on, this code was fixed. If you apply the above two patches and it works
> again, then this isn't the bug you are looking for.
I bisected it again and applied at every step those 2 commits, if commit
2e12978 was in the source too.
Furthermore it was necessary to use a fresh instance of firefox every time to
reproduce a now shomehow changed issue: the UML system wasn't longer
reachable, neither ping nor ssh into it was possible as soon as I tried to
point firefox to https://n22_uml/phpmyadmin/ and no crash occured any longer.
Furthermore a previously opened ssh session to that UML hangs completely.
Bisecting gave :
git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
commit d123375425d7df4b6081a631fc1203fceafa59b2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jan 26 21:32:01 2011 +0100
rwsem: Remove redundant asmregparm annotation
Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
compiling the kernel already with -mregparm=3. So the annotation of
the rwsem functions is redundant. Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David Miller <davem@davemloft.net>
Cc: Chris Zankel <chris@zankel.net>
LKML-Reference:
<alpine.LFD.2.00.1101262130450.31804@localhost6.localdomain6>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
:040000 040000 f373822625e4f5d03d89997cc9f06ef0e21c6d08
272479d3450a4924f3ad2d06a058d77c577ec0d4 M include
:040000 040000 9294321acb9db51e4db72b8e7c95fbd1531a7f26
393fc63299ae482792439384485618a492619787 M lib
/enjoy
:-)
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-20 22:53 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-20 22:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
Steven Rostedt wrote at 18:11:36
> Could you apply these patches:
>
> 2092e6be WARN_ON_SMP(): Allow use in if() statements on UP
> 29096202 futex: Fix WARN_ON() test for UP
>
> On top of this commit, and see if the problem goes away. What could have
> happened, is that you have two bugs, with one of them fixed. If the git
> bisect stumbled on this bug, it will show this one, even though later
> on, this code was fixed. If you apply the above two patches and it works
> again, then this isn't the bug you are looking for.
I bisected it again and applied at every step those 2 commits, if commit
2e12978 was in the source too.
Furthermore it was necessary to use a fresh instance of firefox every time to
reproduce a now shomehow changed issue: the UML system wasn't longer
reachable, neither ping nor ssh into it was possible as soon as I tried to
point firefox to https://n22_uml/phpmyadmin/ and no crash occured any longer.
Furthermore a previously opened ssh session to that UML hangs completely.
Bisecting gave :
git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
commit d123375425d7df4b6081a631fc1203fceafa59b2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jan 26 21:32:01 2011 +0100
rwsem: Remove redundant asmregparm annotation
Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
compiling the kernel already with -mregparm=3. So the annotation of
the rwsem functions is redundant. Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David Miller <davem@davemloft.net>
Cc: Chris Zankel <chris@zankel.net>
LKML-Reference:
<alpine.LFD.2.00.1101262130450.31804@localhost6.localdomain6>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
:040000 040000 f373822625e4f5d03d89997cc9f06ef0e21c6d08
272479d3450a4924f3ad2d06a058d77c577ec0d4 M include
:040000 040000 9294321acb9db51e4db72b8e7c95fbd1531a7f26
393fc63299ae482792439384485618a492619787 M lib
/enjoy
:-)
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 22:53 ` Toralf Förster
(?)
@ 2011-05-21 8:53 ` Toralf Förster
2011-05-23 19:17 ` richard -rw- weinberger
-1 siblings, 1 reply; 58+ messages in thread
From: Toralf Förster @ 2011-05-21 8:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Darren Hart, richard -rw- weinberger, LKML, user-mode-linux-devel
[-- Attachment #1: Type: Text/Plain, Size: 3663 bytes --]
Toralf Förster wrote at 00:53:50
> Bisecting gave :
>
>
> git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad
> commit commit d123375425d7df4b6081a631fc1203fceafa59b2
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date: Wed Jan 26 21:32:01 2011 +0100
>
> rwsem: Remove redundant asmregparm annotation
>
> Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> compiling the kernel already with -mregparm=3. So the annotation of
> the rwsem functions is redundant. Remove it.
BTW I double checked that this commit is the culprit of the hang - it is.
Furthermore I added these kernel config options :
tfoerste@n22 ~/devel/linux-2.6 $ diff .config* | grep '<' | grep -v '#'
< CONFIG_X86_CPU=y
< CONFIG_CMPXCHG_LOCAL=y
< CONFIG_IP_FIB_HASH=y
< CONFIG_RPCSEC_GSS_KRB5=y
< CONFIG_DEBUG_RT_MUTEXES=y
< CONFIG_DEBUG_PI_LIST=y
< CONFIG_DEBUG_MUTEXES=y
< CONFIG_BKL=y
< CONFIG_DEBUG_INFO=y
< CONFIG_DEBUG_WRITECOUNT=y
< CONFIG_DEBUG_LIST=y
< CONFIG_DEBUG_PAGEALLOC=y
< CONFIG_WANT_PAGE_DEBUG_FLAGS=y
< CONFIG_PAGE_POISONING=y
attached gdb to the top process of linx and run wiresahrk in parallel when I did
$>firefox https://n22_uml/phpmyadmin/ &
GDB gave :
Program received signal SIGSEGV, Segmentation fault.
0x0829f2bd in rwsem_down_failed_common (sem=0x84f6000, flags=2, adjustment=65535) at lib/rwsem.c:189
189 adjustment += RWSEM_WAITING_BIAS;
(gdb) bt full
#0 0x0829f2bd in rwsem_down_failed_common (sem=0x84f6000, flags=2, adjustment=65535) at lib/rwsem.c:189
waiter = {list = {next = 0x0, prev = 0x6}, task = 0x1809d480, flags = 2}
tsk = 0x1809d480
count = <value optimized out>
#1 0x0829f375 in rwsem_down_write_failed (sem=0x84f6000) at lib/rwsem.c:236
No locals.
#2 0x0829d0e2 in call_rwsem_down_write_failed () at arch/um/sys-i386/../../x86/lib/semaphore_32.S:97
No locals.
#3 0x0829eaa7 in __down_write_nested (sem=0x182aa774)
at /home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:105
tmp = -1
#4 __down_write (sem=0x182aa774) at /home/tfoerste/devel/linux-2.6/arch/x86/include/asm/rwsem.h:121
No locals.
#5 down_write (sem=0x182aa774) at kernel/rwsem.c:51
No locals.
#6 0x080d2de3 in sys_brk (brk=139419648) at mm/mmap.c:254
rlim = <value optimized out>
newbrk = <value optimized out>
oldbrk = 0
mm = 0x182aa740
#7 0x08060d16 in handle_syscall (r=0x1809d650) at arch/um/kernel/skas/syscall.c:35
syscall = <value optimized out>
#8 0x08074ca1 in handle_trap (regs=0x1809d650) at arch/um/os-Linux/skas/process.c:201
err = <value optimized out>
status = 0
#9 userspace (regs=0x1809d650) at arch/um/os-Linux/skas/process.c:417
sig = <value optimized out>
timer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 5999}}
nsecs = <value optimized out>
err = <value optimized out>
status = 34175
op = 31
pid = 12820
local_using_sysemu = 2
#10 0x0805e0cb in fork_handler () at arch/um/kernel/process.c:181
No locals.
#11 0xaaaaaaaa in ?? ()
No symbol table info available.
(gdb) quit
I attached the wireshark stream onto this mail - the network connections at at packet #92:
TLSv1 754 [TCP Retransmission] Change Cipher Spec, Encrypted Handshake Message, Application Data
might give a hint, that in few cases the UML system even hangs during start of the sshd, isn't it ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: uml_hang.pcap --]
[-- Type: application/octet-stream, Size: 59699 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-20 22:53 ` Toralf Förster
@ 2011-05-21 10:12 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-21 10:12 UTC (permalink / raw)
To: Toralf Förster
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel,
Thomas Gleixner, Peter Zijlstra
2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
> Bisecting gave :
>
>
> git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
> commit d123375425d7df4b6081a631fc1203fceafa59b2
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date: Wed Jan 26 21:32:01 2011 +0100
>
> rwsem: Remove redundant asmregparm annotation
>
> Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> compiling the kernel already with -mregparm=3. So the annotation of
> the rwsem functions is redundant. Remove it.
Ok, this bisect makes much more sense.
Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-21 10:12 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-21 10:12 UTC (permalink / raw)
To: Toralf Förster
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel,
Thomas Gleixner, Peter Zijlstra
2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
> Bisecting gave :
>
>
> git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
> commit d123375425d7df4b6081a631fc1203fceafa59b2
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date: Wed Jan 26 21:32:01 2011 +0100
>
> rwsem: Remove redundant asmregparm annotation
>
> Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> compiling the kernel already with -mregparm=3. So the annotation of
> the rwsem functions is redundant. Remove it.
Ok, this bisect makes much more sense.
Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-21 10:12 ` richard -rw- weinberger
@ 2011-05-21 22:37 ` Peter Zijlstra
-1 siblings, 0 replies; 58+ messages in thread
From: Peter Zijlstra @ 2011-05-21 22:37 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Toralf Förster, Steven Rostedt, Darren Hart, LKML,
user-mode-linux-devel, Thomas Gleixner
On Sat, 2011-05-21 at 12:12 +0200, richard -rw- weinberger wrote:
> 2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
> > Bisecting gave :
> >
> >
> > git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
> > commit d123375425d7df4b6081a631fc1203fceafa59b2
> > Author: Thomas Gleixner <tglx@linutronix.de>
> > Date: Wed Jan 26 21:32:01 2011 +0100
> >
> > rwsem: Remove redundant asmregparm annotation
> >
> > Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> > compiling the kernel already with -mregparm=3. So the annotation of
> > the rwsem functions is redundant. Remove it.
>
> Ok, this bisect makes much more sense.
>
> Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
> We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
> It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
But why?
Also, having to carry that asmregparm notation just for uml doesn't seem
worth the trouble.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-21 22:37 ` Peter Zijlstra
0 siblings, 0 replies; 58+ messages in thread
From: Peter Zijlstra @ 2011-05-21 22:37 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Toralf Förster, Steven Rostedt, Darren Hart, LKML,
user-mode-linux-devel, Thomas Gleixner
On Sat, 2011-05-21 at 12:12 +0200, richard -rw- weinberger wrote:
> 2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
> > Bisecting gave :
> >
> >
> > git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
> > commit d123375425d7df4b6081a631fc1203fceafa59b2
> > Author: Thomas Gleixner <tglx@linutronix.de>
> > Date: Wed Jan 26 21:32:01 2011 +0100
> >
> > rwsem: Remove redundant asmregparm annotation
> >
> > Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> > compiling the kernel already with -mregparm=3. So the annotation of
> > the rwsem functions is redundant. Remove it.
>
> Ok, this bisect makes much more sense.
>
> Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
> We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
> It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
But why?
Also, having to carry that asmregparm notation just for uml doesn't seem
worth the trouble.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-21 22:37 ` Peter Zijlstra
@ 2011-05-21 23:06 ` richard -rw- weinberger
-1 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-21 23:06 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Toralf Förster, Steven Rostedt, Darren Hart, LKML,
user-mode-linux-devel, Thomas Gleixner
On Sun, May 22, 2011 at 12:37 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2011-05-21 at 12:12 +0200, richard -rw- weinberger wrote:
>> 2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
>> > Bisecting gave :
>> >
>> >
>> > git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
>> > commit d123375425d7df4b6081a631fc1203fceafa59b2
>> > Author: Thomas Gleixner <tglx@linutronix.de>
>> > Date: Wed Jan 26 21:32:01 2011 +0100
>> >
>> > rwsem: Remove redundant asmregparm annotation
>> >
>> > Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
>> > compiling the kernel already with -mregparm=3. So the annotation of
>> > the rwsem functions is redundant. Remove it.
>>
>> Ok, this bisect makes much more sense.
>>
>> Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
>> We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
>> It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
>
> But why?
Why reverting?
d123375 effectively reverts commit d50efc6c (x86: fix UML and -regparm=3).
> Also, having to carry that asmregparm notation just for uml doesn't seem
> worth the trouble.
>
Frankly, I don't know why exactly UML breaks without having asmregparm.
I've seen this -regparm=3 thing today the very first time, I'll dig into it...
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-21 23:06 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-21 23:06 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Toralf Förster, Steven Rostedt, Darren Hart, LKML,
user-mode-linux-devel, Thomas Gleixner
On Sun, May 22, 2011 at 12:37 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2011-05-21 at 12:12 +0200, richard -rw- weinberger wrote:
>> 2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
>> > Bisecting gave :
>> >
>> >
>> > git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad commit
>> > commit d123375425d7df4b6081a631fc1203fceafa59b2
>> > Author: Thomas Gleixner <tglx@linutronix.de>
>> > Date: Wed Jan 26 21:32:01 2011 +0100
>> >
>> > rwsem: Remove redundant asmregparm annotation
>> >
>> > Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
>> > compiling the kernel already with -mregparm=3. So the annotation of
>> > the rwsem functions is redundant. Remove it.
>>
>> Ok, this bisect makes much more sense.
>>
>> Thomas, Peter, please revert d123375425d7df4b6081a631fc1203fceafa59b2.
>> We cannot compile UML with -mregparm=3 it would cause a lot of trouble.
>> It would break 32bit UML on 64bit and also on older 32bit systems like RHEL5.
>
> But why?
Why reverting?
d123375 effectively reverts commit d50efc6c (x86: fix UML and -regparm=3).
> Also, having to carry that asmregparm notation just for uml doesn't seem
> worth the trouble.
>
Frankly, I don't know why exactly UML breaks without having asmregparm.
I've seen this -regparm=3 thing today the very first time, I'll dig into it...
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-21 8:53 ` Toralf Förster
@ 2011-05-23 19:17 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-23 19:17 UTC (permalink / raw)
To: Toralf Förster
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel
2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
>
> Toralf Förster wrote at 00:53:50
>> Bisecting gave :
>>
>>
>> git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad
>> commit commit d123375425d7df4b6081a631fc1203fceafa59b2
>> Author: Thomas Gleixner <tglx@linutronix.de>
>> Date: Wed Jan 26 21:32:01 2011 +0100
>>
>> rwsem: Remove redundant asmregparm annotation
>>
>> Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
>> compiling the kernel already with -mregparm=3. So the annotation of
>> the rwsem functions is redundant. Remove it.
>
> BTW I double checked that this commit is the culprit of the hang - it is.
> Furthermore I added these kernel config options :
Toralf,
does this patch fix your problem?
http://userweb.kernel.org/~rw/rwsem.diff
Please do a make clean before rebuilding...
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-23 19:17 ` richard -rw- weinberger
0 siblings, 0 replies; 58+ messages in thread
From: richard -rw- weinberger @ 2011-05-23 19:17 UTC (permalink / raw)
To: Toralf Förster
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel
2011/5/21 Toralf Förster <toralf.foerster@gmx.de>:
>
> Toralf Förster wrote at 00:53:50
>> Bisecting gave :
>>
>>
>> git bisect badd123375425d7df4b6081a631fc1203fceafa59b2 is the first bad
>> commit commit d123375425d7df4b6081a631fc1203fceafa59b2
>> Author: Thomas Gleixner <tglx@linutronix.de>
>> Date: Wed Jan 26 21:32:01 2011 +0100
>>
>> rwsem: Remove redundant asmregparm annotation
>>
>> Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
>> compiling the kernel already with -mregparm=3. So the annotation of
>> the rwsem functions is redundant. Remove it.
>
> BTW I double checked that this commit is the culprit of the hang - it is.
> Furthermore I added these kernel config options :
Toralf,
does this patch fix your problem?
http://userweb.kernel.org/~rw/rwsem.diff
Please do a make clean before rebuilding...
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
2011-05-23 19:17 ` richard -rw- weinberger
@ 2011-05-23 19:48 ` Toralf Förster
-1 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-23 19:48 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 21:17:31
>
> does this patch fix your problem?
> http://userweb.kernel.org/~rw/rwsem.diff
yes :-)
> Please do a make clean before rebuilding...
of course
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine)
@ 2011-05-23 19:48 ` Toralf Förster
0 siblings, 0 replies; 58+ messages in thread
From: Toralf Förster @ 2011-05-23 19:48 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Steven Rostedt, Darren Hart, LKML, user-mode-linux-devel
richard -rw- weinberger wrote at 21:17:31
>
> does this patch fix your problem?
> http://userweb.kernel.org/~rw/rwsem.diff
yes :-)
> Please do a make clean before rebuilding...
of course
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2011-05-23 19:48 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-19 13:26 kernel 2.6.39 (user mode linux) crashes (2.6.38 works fine) Toralf Förster
2011-05-19 16:34 ` Toralf Förster
2011-05-20 6:44 ` richard -rw- weinberger
2011-05-20 6:44 ` richard -rw- weinberger
2011-05-20 7:43 ` Toralf Förster
2011-05-20 7:43 ` Toralf Förster
2011-05-19 17:00 ` richard -rw- weinberger
2011-05-19 17:00 ` richard -rw- weinberger
2011-05-19 17:20 ` Toralf Förster
2011-05-19 17:20 ` Toralf Förster
2011-05-19 17:25 ` richard -rw- weinberger
2011-05-19 17:25 ` richard -rw- weinberger
2011-05-19 20:18 ` Toralf Förster
2011-05-19 20:18 ` Toralf Förster
2011-05-19 20:43 ` Steven Rostedt
2011-05-19 20:43 ` Steven Rostedt
2011-05-20 7:37 ` Toralf Förster
2011-05-20 7:37 ` Toralf Förster
2011-05-20 7:56 ` richard -rw- weinberger
2011-05-20 7:56 ` richard -rw- weinberger
2011-05-20 8:39 ` richard -rw- weinberger
2011-05-20 8:58 ` Toralf Förster
2011-05-20 8:58 ` Toralf Förster
2011-05-20 9:02 ` richard -rw- weinberger
2011-05-20 9:02 ` richard -rw- weinberger
2011-05-20 9:19 ` Toralf Förster
2011-05-20 9:19 ` Toralf Förster
2011-05-20 8:42 ` Toralf Förster
2011-05-20 8:42 ` Toralf Förster
2011-05-20 16:24 ` richard -rw- weinberger
2011-05-20 16:24 ` richard -rw- weinberger
2011-05-20 17:19 ` Steven Rostedt
2011-05-20 17:19 ` Steven Rostedt
2011-05-20 15:55 ` Darren Hart
2011-05-20 15:55 ` Darren Hart
2011-05-20 16:04 ` Steven Rostedt
2011-05-20 16:11 ` Steven Rostedt
2011-05-20 17:10 ` Toralf Förster
2011-05-20 17:10 ` Toralf Förster
2011-05-20 17:44 ` Steven Rostedt
2011-05-20 17:44 ` Steven Rostedt
2011-05-20 17:46 ` Steven Rostedt
2011-05-20 17:46 ` Steven Rostedt
2011-05-20 22:53 ` Toralf Förster
2011-05-20 22:53 ` Toralf Förster
2011-05-21 8:53 ` Toralf Förster
2011-05-23 19:17 ` richard -rw- weinberger
2011-05-23 19:17 ` richard -rw- weinberger
2011-05-23 19:48 ` Toralf Förster
2011-05-23 19:48 ` Toralf Förster
2011-05-21 10:12 ` richard -rw- weinberger
2011-05-21 10:12 ` richard -rw- weinberger
2011-05-21 22:37 ` Peter Zijlstra
2011-05-21 22:37 ` Peter Zijlstra
2011-05-21 23:06 ` richard -rw- weinberger
2011-05-21 23:06 ` richard -rw- weinberger
2011-05-20 17:35 ` Darren Hart
2011-05-20 17:41 ` Steven Rostedt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.