public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* BUGs in 2.6.12-rc2-RT-V0.7.45-01
@ 2005-04-12 22:14 William Weston
  2005-04-12 23:09 ` Ingo Molnar
  0 siblings, 1 reply; 9+ messages in thread
From: William Weston @ 2005-04-12 22:14 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1972 bytes --]

Hello,

These two BUGs showed up in 2.6.12-rc2-RT-V0.7.45-01 on my P4/HT desktop
machine at work:


During boot, after unused kernel memory freed:

BUG: kstopmachine:1072 RT task yield()-ing!
 [<c0103dba>] dump_stack+0x23/0x25 (20)
 [<c0311d3f>] yield+0x67/0x69 (20)
 [<c01439d4>] stop_machine+0xa4/0x15e (40)
 [<c0143abd>] do_stop+0x15/0x77 (20)
 [<c01332cb>] kthread+0xab/0xd3 (48)
 [<c0100fe9>] kernel_thread_helper+0x5/0xb (567844884)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c013cc26>] .... print_traces+0x1b/0x52
.....[<c0103dba>] ..   ( <= dump_stack+0x23/0x25)


Triggered when running 'yum update', followed by system lockup within one 
minute:

BUG: sleeping function called from invalid context python(4302) at kernel/rt.c:1613
in_atomic():1 [00000001], irqs_disabled():1
 [<c0103dba>] dump_stack+0x23/0x25 (20)
 [<c0119ed0>] __might_sleep+0xd8/0xed (36)
 [<c0139bbc>] __spin_lock+0x34/0x50 (24)
 [<c0139bf5>] _spin_lock+0x1d/0x1f (16)
 [<c01465cf>] lock_kprobes+0x17/0x23 (12)
 [<c01122c9>] kprobe_handler+0xa9/0x209 (32)
 [<c011251c>] kprobe_exceptions_notify+0x48/0x13c (28)
 [<c012b65b>] notifier_call_chain+0x25/0x3f (32)
 [<c0104de0>] do_int3+0x47/0x9b (76)
 [<c0103b4e>] int3+0x1e/0x2c (-478200156)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0112244>] .... kprobe_handler+0x24/0x209
.....[<c011251c>] ..   ( <= kprobe_exceptions_notify+0x48/0x13c)
.. [<c013cc26>] .... print_traces+0x1b/0x52
.....[<c0103dba>] ..   ( <= dump_stack+0x23/0x25)


System will lock up at least once a day, starting somewhere around 
2.6.12-rc1-V0.7.43-05 on the P4/HT box.  My Athlon box at home is running 
fine on the latest -RT kernels.

Please let me know if there's any more debugging I can do.


Regards,
--William Weston


--
/* William Weston <weston@sysex.net> */

[-- Attachment #2: Type: TEXT/PLAIN, Size: 11712 bytes --]

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-debug"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_BKL=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_SECCOMP=y
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_PNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=64
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_QLA2XXX=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=y
CONFIG_NETFILTER=y
CONFIG_BRIDGE_NETFILTER=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_IP_SCTP=m
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_HMAC_SHA1=y
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_LLC=m
CONFIG_LLC2=m
CONFIG_NET_PKTGEN=m
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_NETDEVICES=y
CONFIG_TUN=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_NET_TULIP=y
CONFIG_TULIP=m
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
CONFIG_TULIP_NAPI_HW_MITIGATION=y
CONFIG_DE4X5=m
CONFIG_NET_PCI=y
CONFIG_E100=m
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_NS83820=m
CONFIG_NETCONSOLE=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=2
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=m
CONFIG_RTC_HISTOGRAM=m
CONFIG_BLOCKER=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_I915=y
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
CONFIG_I2C_I801=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_USB_AUDIO=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=m
CONFIG_USB_DEBUG=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_AUDIO=m
CONFIG_USB_BLUETOOTH_TTY=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_MON=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_NET2280=m
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_G_SERIAL=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
CONFIG_FS_POSIX_ACL=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
CONFIG_NTFS_RW=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_PROFILING=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_SCHEDSTATS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RT_DEADLOCK_DETECT=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_KPROBES=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_SECLVL=m
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-12 22:14 BUGs in 2.6.12-rc2-RT-V0.7.45-01 William Weston
@ 2005-04-12 23:09 ` Ingo Molnar
  2005-04-12 23:21   ` William Weston
  2005-04-14 21:06   ` William Weston
  0 siblings, 2 replies; 9+ messages in thread
From: Ingo Molnar @ 2005-04-12 23:09 UTC (permalink / raw)
  To: William Weston; +Cc: linux-kernel


* William Weston <weston@sysex.net> wrote:

> Triggered when running 'yum update', followed by system lockup within 
> one minute:
> 
> BUG: sleeping function called from invalid context python(4302) at kernel/rt.c:1613
> in_atomic():1 [00000001], irqs_disabled():1
>  [<c0103dba>] dump_stack+0x23/0x25 (20)
>  [<c0119ed0>] __might_sleep+0xd8/0xed (36)
>  [<c0139bbc>] __spin_lock+0x34/0x50 (24)
>  [<c0139bf5>] _spin_lock+0x1d/0x1f (16)
>  [<c01465cf>] lock_kprobes+0x17/0x23 (12)
>  [<c01122c9>] kprobe_handler+0xa9/0x209 (32)
>  [<c011251c>] kprobe_exceptions_notify+0x48/0x13c (28)

what are you using kprobes for? Do you get lockups even if you disable 
kprobes?

	Ingo

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-12 23:09 ` Ingo Molnar
@ 2005-04-12 23:21   ` William Weston
  2005-04-12 23:26     ` Ingo Molnar
  2005-04-14 21:06   ` William Weston
  1 sibling, 1 reply; 9+ messages in thread
From: William Weston @ 2005-04-12 23:21 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

> > Triggered when running 'yum update', followed by system lockup within 
> > one minute:
> > 
> > BUG: sleeping function called from invalid context python(4302) at kernel/rt.c:1613
> > in_atomic():1 [00000001], irqs_disabled():1
> >  [<c0103dba>] dump_stack+0x23/0x25 (20)
> >  [<c0119ed0>] __might_sleep+0xd8/0xed (36)
> >  [<c0139bbc>] __spin_lock+0x34/0x50 (24)
> >  [<c0139bf5>] _spin_lock+0x1d/0x1f (16)
> >  [<c01465cf>] lock_kprobes+0x17/0x23 (12)
> >  [<c01122c9>] kprobe_handler+0xa9/0x209 (32)
> >  [<c011251c>] kprobe_exceptions_notify+0x48/0x13c (28)
> 
> what are you using kprobes for? Do you get lockups even if you disable 
> kprobes?
> 
> 	Ingo

I'm not using kprobes currently.  I'll recompile and see if the lockups go 
away.

--ww

--
/* William Weston <weston@sysex.net> */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-12 23:21   ` William Weston
@ 2005-04-12 23:26     ` Ingo Molnar
  0 siblings, 0 replies; 9+ messages in thread
From: Ingo Molnar @ 2005-04-12 23:26 UTC (permalink / raw)
  To: William Weston; +Cc: linux-kernel


* William Weston <weston@sysex.net> wrote:

> > what are you using kprobes for? Do you get lockups even if you disable 
> > kprobes?
> 
> I'm not using kprobes currently.  I'll recompile and see if the 
> lockups go away.

ah - it's an 'empty' kprobes check, and python triggered a userspace 
int3. I think kprobes should really get some RCU locking to check its 
handler list, to not slow down normal int3 processing. Meanwhile, 
disabling kprobes in the .config will probably work around this 
particular problem.

	Ingo

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-12 23:09 ` Ingo Molnar
  2005-04-12 23:21   ` William Weston
@ 2005-04-14 21:06   ` William Weston
  2005-04-15  8:01     ` Ingo Molnar
  1 sibling, 1 reply; 9+ messages in thread
From: William Weston @ 2005-04-14 21:06 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wed, 13 Apr 2005, Ingo Molnar wrote:

> what are you using kprobes for? Do you get lockups even if you disable 
> kprobes?

Various processes will lockup on the P4/HT system, usually while under
some load.  The processes cannot be killed.  X will lockup once or twice a
day (which means my console, and thus sysrq, are toast), but I can still
ssh in.  Nothing is logged by the kernel.  Are there any post-lockup 
forensics that can be performed before I reboot?

Regards,
--William Weston

--
/* William Weston <weston@sysex.net> */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-14 21:06   ` William Weston
@ 2005-04-15  8:01     ` Ingo Molnar
  2005-04-16  1:24       ` William Weston
  0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2005-04-15  8:01 UTC (permalink / raw)
  To: William Weston; +Cc: linux-kernel, dwalker, Steven Rostedt


* William Weston <weston@sysex.net> wrote:

> On Wed, 13 Apr 2005, Ingo Molnar wrote:
> 
> > what are you using kprobes for? Do you get lockups even if you disable 
> > kprobes?
> 
> Various processes will lockup on the P4/HT system, usually while under 
> some load.  The processes cannot be killed.  X will lockup once or 
> twice a day (which means my console, and thus sysrq, are toast), but I 
> can still ssh in.  Nothing is logged by the kernel.  Are there any 
> post-lockup forensics that can be performed before I reboot?

could you try the -44-03 patch:

 http://redhat.com/~mingo/realtime-preempt/older/realtime-preempt-2.6.12-rc2-V0.7.44-03

this doesnt have the plist changes yet. Is this one more stable?

	Ingo

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-15  8:01     ` Ingo Molnar
@ 2005-04-16  1:24       ` William Weston
  2005-05-11 19:29         ` Steven Rostedt
  0 siblings, 1 reply; 9+ messages in thread
From: William Weston @ 2005-04-16  1:24 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, dwalker, Steven Rostedt

On Fri, 15 Apr 2005, Ingo Molnar wrote:

> * William Weston <weston@sysex.net> wrote:
> 
> > On Wed, 13 Apr 2005, Ingo Molnar wrote:
> > 
> > > what are you using kprobes for? Do you get lockups even if you disable 
> > > kprobes?
> > 
> > Various processes will lockup on the P4/HT system, usually while under 
> > some load.  The processes cannot be killed.  X will lockup once or 
> > twice a day (which means my console, and thus sysrq, are toast), but I 
> > can still ssh in.  Nothing is logged by the kernel.  Are there any 
> > post-lockup forensics that can be performed before I reboot?
> 
> could you try the -44-03 patch:
> 
>  http://redhat.com/~mingo/realtime-preempt/older/realtime-preempt-2.6.12-rc2-V0.7.44-03
> 
> this doesnt have the plist changes yet. Is this one more stable?

With 2.6.12-rc2-V0.7.44-03, the P4/HT box has been stable all day.  I'm 
seeing another BUG on boot, not kprobes related this time:

Freeing unused kernel memory: 192k freed
logips2pp: Detected unknown logitech mouse model 86
input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
BUG: kstopmachine:1054 RT task yield()-ing!
 [<c0103dba>] dump_stack+0x23/0x25 (20)
 [<c030ff1f>] yield+0x67/0x69 (20)
 [<c0142a44>] stop_machine+0xa4/0x15e (40)
 [<c0142b2d>] do_stop+0x15/0x77 (20)
 [<c0132c5b>] kthread+0xab/0xd3 (48)
 [<c0100fe9>] kernel_thread_helper+0x5/0xb (563617812)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c013bca6>] .... print_traces+0x1b/0x52
.....[<c0103dba>] ..   ( <= dump_stack+0x23/0x25)

ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
eth0: ns83820.c: 0x22c: 49001186, subsystem: 1186:4900
eth0: ns83820 v0.20: DP83820 v1.2: 00:50:ba:37:d4:bc io=0xff8ff000 irq=18 f=sg


I'm also seeing an unlikely wakeup time:

(               X-3581 |#1): new 2533412143 us maximum-latency wakeup.


Otherwise, this on seems very stable.


Best Regards,
--William Weston


--
/* William Weston <weston@sysex.net> */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-04-16  1:24       ` William Weston
@ 2005-05-11 19:29         ` Steven Rostedt
  2005-05-23  7:39           ` Ingo Molnar
  0 siblings, 1 reply; 9+ messages in thread
From: Steven Rostedt @ 2005-05-11 19:29 UTC (permalink / raw)
  To: Ingo Molnar, William Weston; +Cc: linux-kernel, dwalker

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

Hi Ingo,

I've seen lots of complaining about the yield BUG produced by
kstopmachine, and since I'm now starting to test this on an SMP machine,
I'm seeing it too.  So I've looked further into this, and here's what
I've found.

The kstopmachine creates one thread per CPU to run on each CPU.  It sets
this thread to the lowest RT priority and then spins on yield, each
thread expects to be on its designated CPU and spin until all threads
check in (all threads are on their expected CPU).  The yield is only to
allow one of the other threads (of same priority) to migrate to their
expected CPU if it started on the wrong CPU.  So the use of yield here
is actually correct!

So for this special case, I've included a patch here (attached) to allow
for a call of yield when it is actually OK for a RT task to call yield.
It's called rt_yield.  Take a look and see what you think.  I patched
this against 45-01 since that's what I'm currently working with.

-- Steve

On Fri, 2005-04-15 at 18:24 -0700, William Weston wrote:
> On Fri, 15 Apr 2005, Ingo Molnar wrote:
[...]
> 
> With 2.6.12-rc2-V0.7.44-03, the P4/HT box has been stable all day.  I'm 
> seeing another BUG on boot, not kprobes related this time:
> 
> Freeing unused kernel memory: 192k freed
> logips2pp: Detected unknown logitech mouse model 86
> input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
> BUG: kstopmachine:1054 RT task yield()-ing!
>  [<c0103dba>] dump_stack+0x23/0x25 (20)
>  [<c030ff1f>] yield+0x67/0x69 (20)
>  [<c0142a44>] stop_machine+0xa4/0x15e (40)
>  [<c0142b2d>] do_stop+0x15/0x77 (20)
>  [<c0132c5b>] kthread+0xab/0xd3 (48)
>  [<c0100fe9>] kernel_thread_helper+0x5/0xb (563617812)
> ---------------------------
> | preempt count: 00000001 ]
> | 1-level deep critical section nesting:
> ----------------------------------------
> .. [<c013bca6>] .... print_traces+0x1b/0x52
> .....[<c0103dba>] ..   ( <= dump_stack+0x23/0x25)


[-- Attachment #2: rt-yeild.patch --]
[-- Type: text/x-patch, Size: 1906 bytes --]

Index: kernel/stop_machine.c
===================================================================
--- kernel/stop_machine.c	(revision 181)
+++ kernel/stop_machine.c	(working copy)
@@ -56,7 +56,7 @@
 		/* Yield in first stage: migration threads need to
 		 * help our sisters onto their CPUs. */
 		if (!prepared && !irqs_disabled)
-			yield();
+			rt_yield();
 		else
 			cpu_relax();
 	}
@@ -110,7 +110,7 @@
 
 	/* Wait for them all to come to life. */
 	while (atomic_read(&stopmachine_thread_ack) != stopmachine_num_threads)
-		yield();
+		rt_yield();
 
 	/* If some failed, kill them all. */
 	if (ret < 0) {
Index: kernel/sched.c
===================================================================
--- kernel/sched.c	(revision 181)
+++ kernel/sched.c	(working copy)
@@ -4288,7 +4288,7 @@
  * this is a shortcut for kernel-space yielding - it marks the
  * thread runnable and calls sys_sched_yield().
  */
-void __sched yield(void)
+static inline void __sched __yield(int rtok)
 {
 	static int once = 1;
 
@@ -4298,7 +4298,7 @@
 	 * us an idea about the scope of the problem, without spamming
 	 * the syslog:
 	 */
-	if (once && rt_task(current)) {
+	if (!rtok && once && rt_task(current)) {
 		once = 0;
 		printk(KERN_ERR "BUG: %s:%d RT task yield()-ing!\n",
 			current->comm, current->pid);
@@ -4308,7 +4308,18 @@
 	sys_sched_yield();
 }
 
+void __sched yield(void)
+{
+	__yield(0);
+}
+
+void __sched rt_yield(void)
+{
+	__yield(1);
+}
+
 EXPORT_SYMBOL(yield);
+EXPORT_SYMBOL(rt_yield);
 
 /*
  * This task is about to go to sleep on IO.  Increment rq->nr_iowait so
Index: include/linux/sched.h
===================================================================
--- include/linux/sched.h	(revision 181)
+++ include/linux/sched.h	(working copy)
@@ -1007,6 +1007,7 @@
 extern int mutex_getprio(task_t *p);
 
 void yield(void);
+void rt_yield(void);
 
 /*
  * The default (Linux) execution domain.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01
  2005-05-11 19:29         ` Steven Rostedt
@ 2005-05-23  7:39           ` Ingo Molnar
  0 siblings, 0 replies; 9+ messages in thread
From: Ingo Molnar @ 2005-05-23  7:39 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: William Weston, linux-kernel, dwalker


* Steven Rostedt <rostedt@goodmis.org> wrote:

> Hi Ingo,
> 
> I've seen lots of complaining about the yield BUG produced by 
> kstopmachine, and since I'm now starting to test this on an SMP 
> machine, I'm seeing it too.  So I've looked further into this, and 
> here's what I've found.
> 
> The kstopmachine creates one thread per CPU to run on each CPU.  It 
> sets this thread to the lowest RT priority and then spins on yield, 
> each thread expects to be on its designated CPU and spin until all 
> threads check in (all threads are on their expected CPU).  The yield 
> is only to allow one of the other threads (of same priority) to 
> migrate to their expected CPU if it started on the wrong CPU.  So the 
> use of yield here is actually correct!
> 
> So for this special case, I've included a patch here (attached) to 
> allow for a call of yield when it is actually OK for a RT task to call 
> yield. It's called rt_yield.  Take a look and see what you think.  I 
> patched this against 45-01 since that's what I'm currently working 
> with.

agreed - i've applied your patch and i've reworked it to be 
yield()/__yield(). (making it more of an internal interface - this is a 
valid but still quite unrobust use of scheduling features.)

	Ingo

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-05-23  7:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-12 22:14 BUGs in 2.6.12-rc2-RT-V0.7.45-01 William Weston
2005-04-12 23:09 ` Ingo Molnar
2005-04-12 23:21   ` William Weston
2005-04-12 23:26     ` Ingo Molnar
2005-04-14 21:06   ` William Weston
2005-04-15  8:01     ` Ingo Molnar
2005-04-16  1:24       ` William Weston
2005-05-11 19:29         ` Steven Rostedt
2005-05-23  7:39           ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox