Skip to contentSkip to conversation

CONFIG_PREEMPT_REALTIME, 'Fully Preemptible Kernel', VP-2.6.9-rc4-mm1-T4

PATCH In review [email protected] 67 participants 947 messages Oct 11, 2004 – Feb 7, 2005 6 messages not in the archive Page 2 of 5

Subsystems (28)
lore
Share & tools
lore
#155 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 5 lines · On 9:50:08 am 10/18/04 Ingo Molnar <[email protected]> wrote:

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-r
c4-mm1-U5

Im getting this on a make bzImage:

CC fs/xfs/xfs_inode_item.o
fs/xfs/xfs_inode_item.c: In function `xfs_inode_item_pushbuf':
fs/xfs/xfs_inode_item.c:803: error: structure has no member named count' fs/xfs/xfs_inode_item.c:825: error: structure has no member named count' make[2]: *** [fs/xfs/xfs_inode_item.o] Error 1

I'm currently running 2.6.9-rc4-mm1-U1 without error. I backed out the U1 patch, applied the new one, did a make oldconfig, make clean, make bzImage, make modules. My config is attached.

\__ Jason Munro
\__ [email protected]
\__ http://hastymail.sourceforge.net/

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-RT-U5
# Mon Oct 18 10:23:45 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

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

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_TOSHIBA=y
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support #
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set CONFIG_ACPI_THINKPAD=m
CONFIG_ACPI_TOSHIBA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
CONFIG_X86_P4_CLOCKMOD=y
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#

# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_YENTA=y
CONFIG_CARDBUS=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

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

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

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

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

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

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

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

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs #
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE 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_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support #
# CONFIG_PRISM54 is not set CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

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

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

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

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_CS=m
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=m
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

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

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
CONFIG_FONT_6x11=y
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_RW_DETECT is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=m
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_POSIX 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

#
# Native Language Support
#
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 is not set
# 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=y
# 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 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_PREEMPT_TIMING is not set
# CONFIG_RWSEM_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

#156 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 9 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

this is a release intended to increase stability, but since it also includes new debug features and related cleanups it might introduce new regressions. Be careful.

Quoted 7 lines

[snip]

- debug feature: implemented /proc/sys/kernel/trace_verbose runtime flag (default:0), which enables a much more verbose printout in /proc/latency_trace. This trace format can be useful in e.g. debugging timestamp weirdnesses.

With all these proc values, what do you recommend they should be set to?

#157 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 7 lines · Adam Heath
Quoted 4 lines

- debug feature: implemented /proc/sys/kernel/trace_verbose runtime flag (default:0), which enables a much more verbose printout in /proc/latency_trace. This trace format can be useful in e.g. debugging timestamp weirdnesses.

With all these proc values, what do you recommend they should be set to?

just the default values - same for the .config options. Once the feature gets more stable the latency measurements can begin again - for them the /proc values are important.

Ingo

#158 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

EXT3 FS on hda5, internal journal
(mount/71/CPU#0): new 493 us maximum-latency critical section.
=> started at timestamp 29143938: <kernel_fpu_begin+0x21/0x60>
=> ended at timestamp 29144431: <_mmx_memcpy+0x131/0x180>

 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c01e3625>] vgacon_scroll+0x245/0x260
 [<c01f3bba>] scrup+0xda/0xf0
 [<c0113104>] mcount+0x14/0x18
 [<c01f5702>] lf+0x72/0x80
 [<c01f7e9f>] vt_console_print+0x13f/0x320
 [<c011c231>] __call_console_drivers+0x61/0x70
 [<c011c35a>] call_console_drivers+0x9a/0x140
 [<c011c721>] release_console_sem+0x71/0x100
 [<c011c5f6>] vprintk+0x116/0x180
 [<c011c4dd>] printk+0x1d/0x20
 [<c01a0957>] ext3_setup_super+0x127/0x1b0
 [<c01db07f>] up_write+0x4f/0x80
 [<c01a2552>] ext3_remount+0x132/0x190
 [<c01dae41>] down_write+0x71/0xa0
 [<c0162903>] do_remount_sb+0xb3/0xe0
 [<c0179712>] do_remount+0x72/0xc0
 [<c017a073>] do_mount+0x1a3/0x1b0
 [<c01dae41>] down_write+0x71/0xa0
 [<c017a3ec>] sys_mount+0x9c/0x100
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180) .. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

=> dump-end timestamp 29144924

The kernel is jsut getting ready to start init at this point(mounting root), so I don't know if you are really interested in this high latency trace, but I'm sending anyways.

However, after I reset the threshold to 50(and got a few small traces), I got this whopper.

(XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
=> started at timestamp 358506933: <call_console_drivers+0x76/0x140>
=> ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>

 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c02a2859>] __sched_text_start+0x2d9/0x570
 [<c02a3323>] schedule_timeout+0x63/0xc0
 [<c02a316e>] cond_resched+0xe/0x90
 [<c01253a0>] process_timeout+0x0/0x20
 [<c02a3185>] cond_resched+0x25/0x90
 [<c016f592>] do_select+0x172/0x280
 [<c016f280>] __pollwait+0x0/0xb0
 [<c016f984>] sys_select+0x294/0x570
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x570 / (schedule_timeout+0x63/0xc0) .. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

=> dump-end timestamp 358512077

ps: I've never mentioned the hardware I am running. Athlon XP 2000, 1G ram,
460G(usable) software raid5(3*250g ide)(plus boot 120G), LVM, extra SiliconImage UDMA133 controller(mobo can only do 100).

I'm not certain what kind of latencies to expect with this setup. I'm tending to ignore <100us, at least for now.

#159 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 5 lines · Adam Heath

=> dump-end timestamp 29144924

The kernel is jsut getting ready to start init at this point(mounting root), so I don't know if you are really interested in this high latency trace, but I'm sending anyways.

lets skip these for the time being, large runtime ones are the first ones to be squashed.

Quoted 7 lines

However, after I reset the threshold to 50(and got a few small traces), I got this whopper.

(XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
=> started at timestamp 358506933: <call_console_drivers+0x76/0x140>
=> ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
[<c0132480>] sub_preempt_count+0x60/0x90

interesting - this could be a printk (trace) done in a critical section though. What does /proc/latency_trace tell, is it full of console code functions?

one of the best ways to avoid the console-printk-ing overhead is to do a 'dmesg -n 1' and reset the maximum back to 50. (i prefer to use the preempt_max_latency option not the preempt_thresh option.)

Quoted 6 lines

ps: I've never mentioned the hardware I am running. Athlon XP 2000, 1G ram,
460G(usable) software raid5(3*250g ide)(plus boot 120G), LVM, extra SiliconImage UDMA133 controller(mobo can only do 100).

I'm not certain what kind of latencies to expect with this setup. I'm tending to ignore <100us, at least for now.

this setup shouldnt produce above-100 usec latencies with -U5 and PREEMPT_REALTIME.

Ingo

#160 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 11 lines · Ingo Molnar
Quoted 7 lines

However, after I reset the threshold to 50(and got a few small traces), I got this whopper.

(XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
=> started at timestamp 358506933: <call_console_drivers+0x76/0x140>
=> ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
[<c0132480>] sub_preempt_count+0x60/0x90

interesting - this could be a printk (trace) done in a critical section though. What does /proc/latency_trace tell, is it full of console code functions?

Too late, it's gone. It'd be nice if there was some way to have history on that file.

#161 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 10 lines · Adam Heath
Quoted 8 lines · Ingo Molnar
Quoted 7 lines

However, after I reset the threshold to 50(and got a few small traces), I got this whopper.

(XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
=> started at timestamp 358506933: <call_console_drivers+0x76/0x140>
=> ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
[<c0132480>] sub_preempt_count+0x60/0x90

Quoted 6 lines
Quoted 3 lines

interesting - this could be a printk (trace) done in a critical section though. What does /proc/latency_trace tell, is it full of console code functions?

Too late, it's gone. It'd be nice if there was some way to have history on that file.

well - if it's gone it's always replaced by a larger latency (if you use the preempt_max_latency method), which in most cases is more interesting than the one you wanted to save.

Ingo

#162 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 6 lines · Ingo Molnar
Quoted 2 lines

Too late, it's gone. It'd be nice if there was some way to have history on that file.

well - if it's gone it's always replaced by a larger latency (if you use the preempt_max_latency method), which in most cases is more interesting than the one you wanted to save.

I reset the minimum to 50, and it's only gotten up to 83.

#163 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

Ingo,

*** Warning: "__you_cannot_kmalloc_that_much" [drivers/scsi/aacraid/aacraid.ko] undefined!

This just appeared in U5. I was trying to track this one down just because I saw it, even though I don't need aacraid. I am having a hell of a time tracking down what changed that would cause this, but I figure you will know exactly what changed that would cause it. :)

kr

#164 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 8 lines · K.R. Foley
Quoted 4 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

Ingo,

Quoted 7 lines

*** Warning: "__you_cannot_kmalloc_that_much"
[drivers/scsi/aacraid/aacraid.ko] undefined!

This just appeared in U5. I was trying to track this one down just because I saw it, even though I don't need aacraid. I am having a hell of a time tracking down what changed that would cause this, but I figure you will know exactly what changed that would cause it. :)

i suspect this is due to the size increase of semaphores if CONFIG_RWSEM_DEADLOCK_DETECT is enabled. Try lowering CONFIG_RWSEM_MAX_OWNERS from the default 64 to 32, does that help?

Ingo

#165 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 20 lines · Ingo Molnar
Quoted 7 lines · K.R. Foley
Quoted 4 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

Quoted 8 lines

Ingo,

*** Warning: "__you_cannot_kmalloc_that_much" [drivers/scsi/aacraid/aacraid.ko] undefined!

This just appeared in U5. I was trying to track this one down just because I saw it, even though I don't need aacraid. I am having a hell of a time tracking down what changed that would cause this, but I figure you will know exactly what changed that would cause it. :)

Quoted 6 lines

i suspect this is due to the size increase of semaphores if CONFIG_RWSEM_DEADLOCK_DETECT is enabled. Try lowering CONFIG_RWSEM_MAX_OWNERS from the default 64 to 32, does that help?

Ingo

Yes. That does help.

kr

#166 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 3 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

CC arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function) arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

bill

#167 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 5 lines · Bill Huey
Quoted 3 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

Quoted 7 lines

CC arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function) arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it happen with vanilla -mm1 too?

Ingo

#168 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 10 lines · Ingo Molnar
Quoted 8 lines · Bill Huey

CC arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function) arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

Quoted 2 lines

i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it happen with vanilla -mm1 too?

yep, should I wait for -mm2 ?

bill

#169 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 11 lines · Bill Huey
Quoted 10 lines · Ingo Molnar
Quoted 8 lines · Bill Huey

CC arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function) arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

Quoted 4 lines
Quoted 2 lines

i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it happen with vanilla -mm1 too?

yep, should I wait for -mm2 ?

since 2.6.9's release is imminent there will unlikely be an -rc4-mm2, 2.6.9-mm1 should be the next one.

Ingo

#170 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 2 lines · Ingo Molnar

since 2.6.9's release is imminent there will unlikely be an -rc4-mm2, 2.6.9-mm1 should be the next one.

The new kgdb logic is a bit foreign to me. I'll have to look at it a bit more, but this kgdb build problem is criticial for a certain part of the kernel community that needs it. I've commented out that section and rebuilding it now.

To get kgdb work (referencing my tree), I've just demoted all of the spinlocks in arch/i386/{kernel,lib}/kgdb*.c files. It's pretty straight forward, nothing tricky at all.

bill

#171 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Bill Huey (hui)
Quoted 5 lines · Bill Huey
Quoted 3 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

Quoted 7 lines

CC arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function) arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

bah, let me handle this, CONFIG_KGDB was turned on and I'm workin on this now...

bill

#172 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

From the first line of the attached oops file:

kernel BUG at lib/rwsem-generic.c:130!

Then, a BUG, sleeping while atomic.

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: nfsd exportfs snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device 8250 serial_core nfs lockd sunrpc raid5 xor md dm_mirror dm_mod aic7xxx sg sr_mod cdrom sd_mod scsi_mod snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc soundcore 3c59x mii sis900 crc32 siimage
CPU:    0
EIP:    0060:[<c01da56b>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-rt-u5) 

EIP is at rwsem_owner_del+0x6b/0x90
eax: 00000001 ebx: f7b31658 ecx: 00000000 edx: 00000001
esi: 00000000 edi: f7b31658 ebp: d3113f34 esp: d3113f28
ds: 007b es: 007b ss: 0068 preempt: 00000002
Process liquidwar (pid: 6352, threadinfo=d3113000 task=d7ec6e60)

Stack: f7b31658 00000202 d3113fa8 d3113f48 c01db057 f7b31658 f741ac00 d74036c0 
       d3113f64 f88c1c18 d3113f64 c0113104 00000000 f88c1be0 d74036c0 d3113f90 
       c015b61b d74036c0 080d77f8 00000800 d3113fa8 f0d94164 f0d94164 d74036c0 
Call Trace:
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: up_write+0x70/0x80 / (snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]) .. entry 2: die+0x3f/0x1a0 / (do_invalid_op+0x106/0x110)
.. entry 3: print_traces+0x1d/0x70 / (show_stack+0x83/0xa0)

Code: 16 bb 00 f0 ff ff 21 e3 8b 44 8f 10 3b 03 74 28 41 89 d6 39 d1 7c f1 8b 15 b8 fe 2e c0 85 d2 74 12 c7 05 b8 fe 2e c0 00 00 00 00 <0f> 0b 82 00 e1 05 2c c0 5b 5e 5f c9 c3 8d 56 ff 39 d1 74 08 8b 
 <6>note: liquidwar[6352] exited with preempt_count 1
BUG: sleeping function called from invalid context liquidwar(6352) at kernel/fork.c:421
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119582>] __might_sleep+0xc2/0xe0
 [<c0119bce>] mm_release+0x6e/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: task_rq_lock+0x1e/0x30 / (try_to_wake_up+0x2d/0xc0) .. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

BUG: scheduling while atomic: liquidwar/0x04000001/6352
caller is cond_resched+0x62/0x90
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0119bd3>] mm_release+0x73/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: __do_IRQ+0x111/0x190 / (do_IRQ+0x75/0xa0) .. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

BUG: scheduling while atomic: liquidwar/0x00000001/6352
caller is do_exit+0x292/0x4a0
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c0113104>] mcount+0x14/0x18
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __do_IRQ+0x111/0x190 / (do_IRQ+0x75/0xa0) .. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

ksymoops 2.4.9 on i686 2.6.9-rc4-mm1-rt-u5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.9-rc4-mm1-rt-u5/ (default) -m /boot/System.map-2.6.9-rc4-mm1-rt-u5 (default)

Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects
No ksyms, skipping lsmod

 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dae41>] down_write+0x71/0xa0
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c01da9be>] __up_write+0xe/0x1b0
 [<c01db05f>] up_write+0x2f/0x80
 [<c0113104>] mcount+0x14/0x18
 [<c016ea97>] sys_ioctl+0x47/0x230
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c015c604>] fget_light+0x14/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c015b6e0>] sys_read+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c499b>] avc_has_perm_noaudit+0x7b/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01183ee>] __wake_up+0x5e/0x90
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c015c604>] fget_light+0x14/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0113104>] mcount+0x14/0x18
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c015c67f>] fget_light+0x8f/0xa0
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c0176db9>] inode_times_differ+0x9/0x50
 [<c0176f6f>] inode_update_time+0x9f/0xe0
 [<c0113104>] mcount+0x14/0x18
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0113104>] mcount+0x14/0x18
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c015c67f>] fget_light+0x8f/0xa0
 [<c015b6e0>] sys_read+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dafff>] up_read+0x4f/0x80
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01cabcf>] selinux_ip_postroute_last+0x1bf/0x2a0
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01cabcf>] selinux_ip_postroute_last+0x1bf/0x2a0
 [<c0113104>] mcount+0x14/0x18
 [<c01cacea>] selinux_ipv4_postroute_last+0x3a/0x40
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c024fe65>] nf_iterate+0x75/0xb0
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c0250280>] nf_hook_slow+0x90/0x140
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c02610e3>] ip_finish_output+0x223/0x230
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c0261716>] ip_queue_xmit+0x3d6/0x540
 [<c01c4bd1>] avc_has_perm+0x71/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01dafff>] up_read+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c027842e>] tcp_v4_send_check+0xe/0xf0
 [<c0272119>] tcp_transmit_skb+0x439/0x860
 [<c0113104>] mcount+0x14/0x18
 [<c027846f>] tcp_v4_send_check+0x4f/0xf0
 [<c02721c2>] tcp_transmit_skb+0x4e2/0x860
 [<c0113104>] mcount+0x14/0x18
 [<c0274d76>] tcp_send_ack+0xa6/0xf0
 [<c026fdf4>] __tcp_ack_snd_check+0x14/0xa0
 [<c0270427>] tcp_rcv_established+0x287/0x900
 [<c013193d>] __mcount+0x1d/0x20
 [<c027965d>] tcp_v4_do_rcv+0xd/0x120
 [<c0279e7b>] tcp_v4_rcv+0x70b/0x950
 [<c0113104>] mcount+0x14/0x18
 [<c0279765>] tcp_v4_do_rcv+0x115/0x120
 [<c0279e7b>] tcp_v4_rcv+0x70b/0x950
 [<c025db75>] ip_local_deliver+0xf5/0x250
 [<c025df31>] ip_rcv+0x261/0x4c0
 [<c01dae41>] down_write+0x71/0xa0
 [<c0245570>] netif_receive_skb+0x1b0/0x280
 [<c0130008>] nanosleep_wake_up+0x18/0x20
 [<c024564e>] process_backlog+0xe/0x150
 [<c024580f>] net_rx_action+0x7f/0x150
 [<c02456c8>] process_backlog+0x88/0x150
 [<c024580f>] net_rx_action+0x7f/0x150
 [<c0120f87>] ___do_softirq+0x87/0xd0
 [<c0121058>] _do_softirq+0x8/0x30
 [<c01213a4>] ksoftirqd+0x94/0xe0
 [<c0121070>] _do_softirq+0x20/0x30
 [<c01213a4>] ksoftirqd+0x94/0xe0
 [<c013072a>] kthread+0xaa/0xb0
 [<c0121310>] ksoftirqd+0x0/0xe0
 [<c0130680>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c01da56b>]    Not tainted VLI

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002 (2.6.9-rc4-mm1-rt-u5)
eax: 00000001 ebx: f7b31658 ecx: 00000000 edx: 00000001
esi: 00000000 edi: f7b31658 ebp: d3113f34 esp: d3113f28
ds: 007b es: 007b ss: 0068 preempt: 00000002

Stack: f7b31658 00000202 d3113fa8 d3113f48 c01db057 f7b31658 f741ac00 d74036c0 
       d3113f64 f88c1c18 d3113f64 c0113104 00000000 f88c1be0 d74036c0 d3113f90 
       c015b61b d74036c0 080d77f8 00000800 d3113fa8 f0d94164 f0d94164 d74036c0 
Call Trace:
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

Warning (Oops_read): Code line not seen, dumping what data is available

Quoted 6 lines
Quoted 6 lines

EIP; c01da56b <rwsem_owner_del+6b/90> <=====

ebx; f7b31658 <pg0+37735658/3fc02400>
edi; f7b31658 <pg0+37735658/3fc02400>
ebp; d3113f34 <pg0+12d17f34/3fc02400>
esp; d3113f28 <pg0+12d17f28/3fc02400>

Trace; c01db057 <up_write+27/80>
Trace; f88c1c18 <pg0+384c5c18/3fc02400>
Trace; c0113104 <mcount+14/18>
Trace; f88c1be0 <pg0+384c5be0/3fc02400>
Trace; c015b61b <vfs_write+cb/140>
Trace; c015b760 <sys_write+50/80>
Trace; c0106013 <syscall_call+7/b>

Code: 16 bb 00 f0 ff ff 21 e3 8b 44 8f 10 3b 03 74 28 41 89 d6 39 d1 7c f1 8b 15 b8 fe 2e c0 85 d2 74 12 c7 05 b8 fe 2e c0 00 00 00 00 <0f> 0b 82 00 e1 05 2c c0 5b 5e 5f c9 c3 8d 56 ff 39 d1 74 08 8b 

This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt.

Code; c01da540 <rwsem_owner_del+40/90>
00000000 <_EIP>:
Code; c01da540 <rwsem_owner_del+40/90>
0: 16 push %ss
Code; c01da541 <rwsem_owner_del+41/90>
1: bb 00 f0 ff ff mov $0xfffff000,%ebx
Code; c01da546 <rwsem_owner_del+46/90>
6: 21 e3 and %esp,%ebx
Code; c01da548 <rwsem_owner_del+48/90>
8: 8b 44 8f 10 mov 0x10(%edi,%ecx,4),%eax
Code; c01da54c <rwsem_owner_del+4c/90>
c: 3b 03 cmp (%ebx),%eax
Code; c01da54e <rwsem_owner_del+4e/90>
e: 74 28 je 38 <_EIP+0x38>
Code; c01da550 <rwsem_owner_del+50/90>
10: 41 inc %ecx
Code; c01da551 <rwsem_owner_del+51/90>
11: 89 d6 mov %edx,%esi
Code; c01da553 <rwsem_owner_del+53/90>
13: 39 d1 cmp %edx,%ecx
Code; c01da555 <rwsem_owner_del+55/90>
15: 7c f1 jl 8 <_EIP+0x8>
Code; c01da557 <rwsem_owner_del+57/90>
17: 8b 15 b8 fe 2e c0 mov 0xc02efeb8,%edx
Code; c01da55d <rwsem_owner_del+5d/90>
1d: 85 d2 test %edx,%edx
Code; c01da55f <rwsem_owner_del+5f/90>
1f: 74 12 je 33 <_EIP+0x33>
Code; c01da561 <rwsem_owner_del+61/90>
21: c7 05 b8 fe 2e c0 00 movl $0x0,0xc02efeb8
Code; c01da568 <rwsem_owner_del+68/90>
28: 00 00 00

This decode from eip onwards should be reliable

Code; c01da56b <rwsem_owner_del+6b/90>
00000000 <_EIP>:
Code; c01da56b <rwsem_owner_del+6b/90>
0: 0f 0b ud2a
Code; c01da56d <rwsem_owner_del+6d/90>
2: 82 (bad)
Code; c01da56e <rwsem_owner_del+6e/90>
3: 00 e1 add %ah,%cl
Code; c01da570 <rwsem_owner_del+70/90>
5: 05 2c c0 5b 5e add $0x5e5bc02c,%eax
Code; c01da575 <rwsem_owner_del+75/90>
a: 5f pop %edi
Code; c01da576 <rwsem_owner_del+76/90>
b: c9 leave
Code; c01da577 <rwsem_owner_del+77/90>
c: c3 ret
Code; c01da578 <rwsem_owner_del+78/90>
d: 8d 56 ff lea 0xffffffff(%esi),%edx
Code; c01da57b <rwsem_owner_del+7b/90>
10: 39 d1 cmp %edx,%ecx
Code; c01da57d <rwsem_owner_del+7d/90>
12: 74 08 je 1c <_EIP+0x1c>
Code; c01da57f <rwsem_owner_del+7f/90>
14: 8b .byte 0x8b

 [<c0119582>] __might_sleep+0xc2/0xe0
 [<c0119bce>] mm_release+0x6e/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0119bd3>] mm_release+0x73/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c0113104>] mcount+0x14/0x18
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

2 warnings and 1 error issued. Results may not be reliable.

#173 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 2 lines · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

starting nfsd triggers the deadlock detection, but it's not really a deadlock.

The first nfsd thread acquires nlmsvc_sema. The other 7 nfsd threads wait on it. The first thread creates lockd and tries to get lockd_start, which is initialized locked and will be released when the lockd thread starts. The deadlock complains about a deadlock on nlmsvc_sema inside of down(&lockd_start). ?

Converting lockd_start to a waitqueue solves the problem and is more sane, than the locked mutex.

tglx

--- 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c.orig 2004-10-19
10:02:17.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c 2004-10-19 09:54:22.000000000 +0200
@@ -46,7 +46,7 @@
int nlmsvc_grace_period;
unsigned long nlmsvc_timeout;

-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);

/*
@@ -109,7 +109,7 @@

         * Let our maker know we're running.
         */
        nlmsvc_pid = current->pid;

- up(&lockd_start);
+ wake_up(&lockd_start);

        daemonize("lockd");

@@ -230,6 +230,7 @@

                printk(KERN_WARNING
                        "lockd_up: no pid, %d users??\n", nlmsvc_users);

+

        error = -ENOMEM;
        serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
        if (!serv) {
@@ -258,7 +259,19 @@
                        "lockd_up: create thread failed, error=%d\n",
error);
                goto destroy_and_out;
        }
-       down(&lockd_start);
+       /*
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */
+       clear_thread_flag(TIF_SIGPENDING);
+       interruptible_sleep_on_timeout(&lockd_start, HZ);
+       if (!nlmsvc_pid) {
+               printk(KERN_WARNING
+                       "lockd_down: lockd failed to start\n");
+       }
+       spin_lock_irq(&current->sighand->siglock);
+       recalc_sigpending();
+       spin_unlock_irq(&current->sighand->siglock);

/*
* Note: svc_serv structures have an initial use count of 1,
@@ -423,7 +436,6 @@

static int __init init_nlm(void)
{

-       init_MUTEX_LOCKED(&lockd_start);
        nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
        return nlm_sysctl_table ? 0 : -ENOMEM;

}

Installing knfsd (copyright (C) 1996 [email protected]).
mountdBUG: semaphore deadlock detected!
.. task nfsd/1246 is holding c89f4560.
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

       00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
Call Trace:
 [<c0117fc7>] copy_process+0x5f7/0xc30
 [<c01c4e62>] __delay+0x12/0x20
 [<c01fe460>] serial8250_console_write+0x170/0x280
 [<c011930e>] __call_console_drivers+0x5e/0x60
 [<c011982a>] release_console_sem+0xda/0xe0
 [<c01196a7>] vprintk+0x107/0x160
 [<c01196a7>] vprintk+0x107/0x160
 [<c012a3ae>] __kernel_text_address+0x2e/0x40
 [<c0106bf5>] show_trace+0x35/0x90
 [<c0106bf5>] show_trace+0x35/0x90
 [<c0106cd0>] show_stack+0x80/0xa0
 [<c01c2976>] __rwsem_deadlock+0x136/0x180
 [<c01c28aa>] __rwsem_deadlock+0x6a/0x180
 [<c02c3c33>] __down_write+0x93/0x170
 [<c01c3033>] down_write+0x43/0x80
 [<c89e661d>] lockd_up+0x9d/0x120 [lockd]
 [<c89e62e0>] lockd+0x0/0x2a0 [lockd]
 [<c883d2e1>] nfsd+0x91/0x380 [nfsd]
 [<c0105e12>] ret_from_fork+0x6/0x14
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c0103ffd>] kernel_thread_helper+0x5/0x18
...#0 task nfsd/1246 is holding c89f4560.
BUG: semaphore deadlock: nfsd/1252 is blocked on c89f4560, deadlocking
nfsd/1246
c733df60 00000046 c7adad10 c03d6060 00000000 00000000 00000000 00000000
       00000000 00000000 c7a306f0 00005b6e 39133ac7 0000001a c7adae6c
c7adad10
       c7adad10 c7584400 00000000 c02c3cad c89f4560 c6853f6c c6819f6c
c7adad10
Call Trace:
 [<c02c3cad>] __down_write+0x10d/0x170
 [<c01c3033>] down_write+0x43/0x80
 [<c89e6591>] lockd_up+0x11/0x120 [lockd]
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c883d2e1>] nfsd+0x91/0x380 [nfsd]
 [<c0105e12>] ret_from_fork+0x6/0x14
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c0103ffd>] kernel_thread_helper+0x5/0x18
------------[ cut here ]------------
#174 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 1 line · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

All sleep_on variants trigger the irqs_disabled() check in schedule(). tglx

#175 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 5 lines · Thomas Gleixner
Quoted 1 line · Ingo Molnar

i have released the -U5 Real-Time Preemption patch:

All sleep_on variants trigger the irqs_disabled() check in schedule(). tglx

ah, forgot that the waitqueue lock is a raw lock. Is there _any_ scenario where sleep_on() is actually correct kernel code?

Ingo

#176 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 5 lines · Ingo Molnar
Quoted 2 lines

All sleep_on variants trigger the irqs_disabled() check in schedule(). tglx

ah, forgot that the waitqueue lock is a raw lock. Is there _any_ scenario where sleep_on() is actually correct kernel code?

Hmm, the sleep_on() variants are used quite a lot over the kernel. Whats wrong with them and to what should they be converted ?

tglx

#177 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 9 lines · Thomas Gleixner
Quoted 5 lines · Ingo Molnar
Quoted 2 lines

All sleep_on variants trigger the irqs_disabled() check in schedule(). tglx

ah, forgot that the waitqueue lock is a raw lock. Is there _any_ scenario where sleep_on() is actually correct kernel code?

Hmm, the sleep_on() variants are used quite a lot over the kernel. Whats wrong with them and to what should they be converted ?

they are racy on SMP. It does:

	current->state = TASK_INTERRUPTIBLE;

	schedule();

which is almost always a bug to go to sleep via sleep_on() _after_ checking for the condition, because the following could happen:

	CPU1				CPU2

	if (condition)
		goto done;

					wake_up(&waitqueue);

	current->state = TASK_INTERRUPTIBLE;

	schedule();

The proper interface is wait_event() (and variants).

your patch probably only works due to timing - the wakeup always happens after sleep_on() has been called.

this particular NFS case is probably only correct due to userspace behavior. The code is apparently relying on the wake_up() never happening _before_ we do the sleep_on().

so, could you try the init_MUTEX_LOCKED() fix plus the patch below - does that turn off the deadlock assert? (Plus also uncomment the RWSEM_BUG() around line 130.)

Ingo

lib/rwsem-generic.c renamed from lib/rwsem-generic.c.orig +9 -0
@@ -750,6 +750,15 @@ void fastcall sema_init(struct semaphore
 	case 0:
 		init_rwsem(&sem->lock);
 		down(sem);
+#ifdef CONFIG_RWSEM_DEADLOCK_DETECT
+		{
+			unsigned long flags;
+
+			rwsem_lock_irqsave(&rwsem_lock, flags);
+			rwsem_owner_del(&sem->lock);
+			rwsem_unlock_irqrestore(&rwsem_lock, flags);
+		}
+#endif
 		break;
 	default:
 		RWSEM_BUG();
#178 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 3 lines · Ingo Molnar

so, could you try the init_MUTEX_LOCKED() fix plus the patch below - does that turn off the deadlock assert? (Plus also uncomment the RWSEM_BUG() around line 130.)

but i agree with you that this semaphore (ab-)use in the NFS code should be fixed. Best would be to use a completion, but unfortunately there's no wait_for_completion_timeout() API right now.

Ingo

#179 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar
Quoted 2 lines

Hmm, the sleep_on() variants are used quite a lot over the kernel. Whats wrong with them and to what should they be converted ?

they are racy on SMP. It does:
The proper interface is wait_event() (and variants).

Sorry for beeing stupid. I remebered the wait_event stuff immidiately after hitting send (:

Quoted 6 lines

your patch probably only works due to timing - the wakeup always happens after sleep_on() has been called.

this particular NFS case is probably only correct due to userspace behavior. The code is apparently relying on the wake_up() never happening _before_ we do the sleep_on().

Correct fix appended. I think it's more sane than the locked mutex, as we actually come back if lockd is not started for any reason.

Quoted 3 lines

so, could you try the init_MUTEX_LOCKED() fix plus the patch below - does that turn off the deadlock assert? (Plus also uncomment the RWSEM_BUG() around line 130.)

Yep, that fixes the problem

tglx

--- 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c.orig 2004-10-19 10:02:17.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c 2004-10-19 11:34:12.000000000
+0200
@@ -46,7 +46,7 @@
int nlmsvc_grace_period;
unsigned long nlmsvc_timeout;

-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);

/*
@@ -109,7 +109,7 @@

         * Let our maker know we're running.
         */
        nlmsvc_pid = current->pid;

- up(&lockd_start);
+ wake_up(&lockd_start);

        daemonize("lockd");

@@ -230,6 +230,7 @@

                printk(KERN_WARNING
                        "lockd_up: no pid, %d users??\n", nlmsvc_users);

+

        error = -ENOMEM;
        serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
        if (!serv) {
@@ -258,8 +259,15 @@
                        "lockd_up: create thread failed, error=%d\n",
error);
                goto destroy_and_out;
        }
-       down(&lockd_start);
-
+       /*
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */

+ if (wait_event_interruptible_timeout(lockd_start,
+ nlmsvc_pid != 0, HZ)) {
+ printk(KERN_WARNING
+ "lockd_down: lockd failed to start\n");
+ }
/*
* Note: svc_serv structures have an initial use count of 1,
* so we exit through here on both success and failure.
@@ -298,16 +306,12 @@
* Wait for the lockd process to exit, but since we're holding
* the lockd semaphore, we can't wait around forever ... */

-       clear_thread_flag(TIF_SIGPENDING);
-       interruptible_sleep_on_timeout(&lockd_exit, HZ);
-       if (nlmsvc_pid) {
+       if (wait_event_interruptible_timeout(lockd_exit,
+                                            nlmsvc_pid == 0, HZ)) {
                printk(KERN_WARNING
                        "lockd_down: lockd failed to exit, clearing
pid\n");
                nlmsvc_pid = 0;
        }
-       spin_lock_irq(&current->sighand->siglock);
-       recalc_sigpending();
-       spin_unlock_irq(&current->sighand->siglock);
 out:
        up(&nlmsvc_sema);

}
@@ -423,7 +427,6 @@

static int __init init_nlm(void)
{

-       init_MUTEX_LOCKED(&lockd_start);
        nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
        return nlm_sysctl_table ? 0 : -ENOMEM;

}

#180 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Review

Quoted 7 lines · Thomas Gleixner
(quoted diff) +7 -0
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */
+       if (wait_event_interruptible_timeout(lockd_start,
+                                            nlmsvc_pid != 0, HZ)) {
+               printk(KERN_WARNING
+                       "lockd_down: lockd failed to start\n");

yeah, this is much cleaner. I'd suggest to remove the init_sem() hack from lib/rwsem-generic.c, it seems it is a nice facility to find semaphore abuses.

Ingo

#181 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

Quoted 11 lines · Ingo Molnar

Review

Quoted 7 lines · Thomas Gleixner
(quoted diff) +7 -0
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */
+       if (wait_event_interruptible_timeout(lockd_start,
+                                            nlmsvc_pid != 0, HZ)) {
+               printk(KERN_WARNING
+                       "lockd_down: lockd failed to start\n");

yeah, this is much cleaner.

Cleaner, but not perfect. The return value is > 0, if the timeout is not reached. Grmbl.

Quoted 3 lines

I'd suggest to remove the init_sem() hack
from lib/rwsem-generic.c, it seems it is a nice facility to find semaphore abuses.

True. Will do so.

tglx

fs/lockd/svc.c renamed from fs/lockd/svc.c.orig +14 -11
@@ -46,7 +46,7 @@
 int				nlmsvc_grace_period;
 unsigned long			nlmsvc_timeout;
 
-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);
 
 /*
@@ -109,7 +109,7 @@
 	 * Let our maker know we're running.
 	 */
 	nlmsvc_pid = current->pid;
-	up(&lockd_start);
+	wake_up(&lockd_start);
 
 	daemonize("lockd");
 
@@ -230,6 +230,7 @@
 		printk(KERN_WARNING
 			"lockd_up: no pid, %d users??\n", nlmsvc_users);
 
+
 	error = -ENOMEM;
 	serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
 	if (!serv) {
@@ -258,8 +259,15 @@
 			"lockd_up: create thread failed, error=%d\n", error);
 		goto destroy_and_out;
 	}
-	down(&lockd_start);
-
+	/*
+	 * Wait for the lockd process to start, but since we're holding
+	 * the lockd semaphore, we can't wait around forever ...
+	 */
+	if (wait_event_interruptible_timeout(lockd_start, 
+					     nlmsvc_pid != 0, HZ) <= 0) {
+		printk(KERN_WARNING 
+			"lockd_down: lockd failed to start\n");
+	}
 	/*
 	 * Note: svc_serv structures have an initial use count of 1,
 	 * so we exit through here on both success and failure.
@@ -298,16 +306,12 @@
 	 * Wait for the lockd process to exit, but since we're holding
 	 * the lockd semaphore, we can't wait around forever ...
 	 */
-	clear_thread_flag(TIF_SIGPENDING);
-	interruptible_sleep_on_timeout(&lockd_exit, HZ);
-	if (nlmsvc_pid) {
+	if (!wait_event_interruptible_timeout(lockd_exit, 
+					     nlmsvc_pid == 0, HZ) <= 0) {
 		printk(KERN_WARNING 
 			"lockd_down: lockd failed to exit, clearing pid\n");
 		nlmsvc_pid = 0;
 	}
-	spin_lock_irq(&current->sighand->siglock);
-	recalc_sigpending();
-	spin_unlock_irq(&current->sighand->siglock);
 out:
 	up(&nlmsvc_sema);
 }
@@ -423,7 +427,6 @@
 
 static int __init init_nlm(void)
 {
-	init_MUTEX_LOCKED(&lockd_start);
 	nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
 	return nlm_sysctl_table ? 0 : -ENOMEM;
 }
#182 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5

In reply to Ingo Molnar
Quoted 8 lines · Ingo Molnar

there are two big changes:

- debug feature: automatic semaphore/rwsem deadlock detection, based on the code from Igor Manyilov and Bill Huey.

this is a very nice feature that should help in debugging the remaining deadlocks. The deadlock detection feature has already helped me fix a bug that was causing hangs in the VFS, so it's really useful.

I can trigger the deadlock detection when I try to ping my default gateway. I'm attaching the log from dmesg.

Michal

BUG: semaphore deadlock detected!
.. task ksoftirqd/0/2 is holding c04019c4.
0000012c 00000001 c14f4000 00000000 c14f5f9c c011e713 c03a36b8 c011e7d9 
       c011eb18 0000000a c03a36b8 c14f4000 c14f4000 00000000 c14f5fa4 c011e7f1 
       c14f5fbc c011eb18 00000001 fffffff6 c14f4000 c14e3f70 c14f5fec c012d333 
Call Trace:
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: print_traces+0x1d/0x56 / (show_stack+0x85/0x9b)

...#0 task ksoftirqd/0/2 is holding c04019c4.

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:416!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: ipt_REJECT ipt_pkttype ipt_LOG ipt_state ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables af_packet 8139too 8139cp mii crc32 e1000 snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd usbhid uhci_hcd usbcore intel_mch_agp intel_agp evdev nls_iso8859_1 nls_cp437 vfat fat dm_mod floppy ide_cd cdrom psmouse unix
CPU:    0
EIP:    0060:[<c0289aca>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U5) 

EIP is at __down_write+0xad/0x190
eax: 00000001 ebx: c14e0d20 ecx: 00000000 edx: c14f4000
esi: c04019c4 edi: dff1b080 ebp: c14f5d64 esp: c14f5d48
ds: 007b es: 007b ss: 0068 preempt: 00000003
Process ksoftirqd/0 (pid: 2, threadinfo=c14f4000 task=c14e0d20)

Stack: c04019c4 c04019c8 c04019c8 c14e0d20 00000002 c14f4000 c04019c4 c14f5d7c 
       c01b33c8 c04019c4 c14e0d20 dec0f000 df59a000 c14f5da0 c02364c5 c04019c0 
       00000202 c14f5da0 df59a000 dec0f000 df59a000 df59a358 c14f5dc4 c02420cd 
Call Trace:
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: die+0x3f/0x196 / (do_invalid_op+0x106/0x108) .. entry 4: print_traces+0x1d/0x56 / (show_stack+0x85/0x9b)

Code: 10 89 45 ec 89 34 24 e8 47 90 f2 ff 89 34 24 e8 04 91 f2 ff 85 c0 74 1b a1 58 36 2d c0 85 c0 74 12 c7 05 58 36 2d c0 00 00 00 00 <0f> 0b a0 01 2f 32 2a c0 89 b3 70 06 00 00 9c 58 c1 e8 09 83 f0 
 <3>BUG: sleeping function called from invalid context ksoftirqd/0(2) at lib/rwsem-generic.c:593
in_atomic():1 [00000002], irqs_disabled():0
 [<c0116e6c>] __might_sleep+0xc4/0xd6
 [<c01b3275>] down_read+0x27/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

BUG: scheduling while atomic: ksoftirqd/0/0x04000002/2
caller is cond_resched+0x62/0x82
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01132d0>] mcount+0x14/0x18
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01b327a>] down_read+0x2c/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
(ksoftirqd/0/2/CPU#0): new 856 us maximum-latency critical section.
 => started at timestamp 144481672: <__call_console_drivers+0x19/0x65>
 =>   ended at timestamp 144482528: <call_console_drivers+0x9e/0x13f>
 [<c012ec10>] touch_preempt_timing+0x3d/0x41
 [<c012eb37>] check_preempt_timing+0x1b2/0x24e
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c012ec10>] touch_preempt_timing+0x3d/0x41
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c0288edb>] preempt_schedule+0x11/0x7a
 [<c0119e04>] release_console_sem+0x70/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119bc8>] printk+0x1d/0x21
 [<c01055f8>] show_trace+0x78/0xb2
 [<c0289aca>] __down_write+0xad/0x190
 [<c01056f0>] dump_stack+0x23/0x27
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01132d0>] mcount+0x14/0x18
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01b327a>] down_read+0x2c/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

=> dump-end timestamp 144483248

 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

note: ksoftirqd/0[2] exited with preempt_count 2

BUG: scheduling while atomic: ksoftirqd/0/0x00000002/2
caller is do_exit+0x2a7/0x4a3
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c011c247>] do_exit+0x2a7/0x4a3
 [<c01132d0>] mcount+0x14/0x18
 [<c011c247>] do_exit+0x2a7/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127) .. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97) .. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

#183 lore raw

PATCH 1/1 Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Ingo Molnar

i have released the -U6 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

this is a fixes-only release.

found and fixed the 'big bug' that was probably the one causing stability problems for a number of people. There was a small window for a task double-free race to occur, causing all sorts of crashes later on. This bug could trigger on UP and SMP systems alike, on SMP being a bit more frequent.

Also, a common networking deadlock was found and fixed as well, using the deadlock detector.

Changes since -U5:

- crash bug: fix task double free caused by irq-preemption of do_exit(). This got introduced in -U5 as part of a simplification of the zombie-reaping rewrite that the -U series did. That rewrite had an unrobustness which got triggered by -U5 in a subtle way, opening up a small window at the end of do_exit() for an interrupt-triggered preemption to cause a double-free. This could fix some of the crashes reported by Rui Nuno Capela, Mark H Johnson.

- deadlock bug: fix networking deadlock reported by Matthew L Foster. Restructured the way the RT-RCU locking of ptype_lock is done - it's cleaner and more obvious now (besides being correct). This could also fix the deadlock reported by Michal Schmidt.

- deadlock bug: fix NFS startup breakage related to semaphore abuse, patch from Thomas Gleixner.

- build bug: fix aha152x.c, based on patch from K.R. Foley.

- build bug: fix compilation error in qla2xxx. (reported by Fernando Pablo Lopez-Lezcano and Mark H Johnson)

- build bug: fix !PREEMPT_REALTIME compilation error. (reported by Matthew L Foster)

- build bug: fix ipmi-watchdog compilation error. (reported by Mark H Johnson)

- tracer fix: if an assert happens within the tracer then we'd get into infinite recursion. The fix was to correctly nest tracing on/off points.

- debug enhancement: added a few more asserts to catch underflowing atomic counters. (this made the task double-free trigger earlier.)

- debug enhancement: extended CONFIG_DEBUG_STACKOVERFLOW to be mcount()-driven as well. This helps in catching stack overflows much more reliably than the do_IRQ() based method.

to create a -U6 tree from scratch, the patching order is:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
+ http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
+ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
+ http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

Ingo

#184 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 3 lines · Ingo Molnar

i have released the -U6 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

i've re-released the patch because shortly after releasing it i found a false-positive in the deadlock-detector that was triggering in oowriter.

The latest patch is thus:

 $ md5sum realtime-preempt-2.6.9-rc4-mm1-U6
 9fd546bdd2d45ff1a8d5a88160135170  realtime-preempt-2.6.9-rc4-mm1-U6

if you've got the earlier one and have CONFIG_RWSEM_DEADLOCK_DETECT enabled then please download the new patch.

Ingo

#185 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 5 lines · Ingo Molnar
Quoted 4 lines

i have released the -U6 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

I'm experiencing terrible kernel panics at a very early bootstrap stage while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) -- (Ingo: this is about the very same trouble I've reported while pre-testing U6).

Sorry that I can't show any trace dumps; only a hard-screenshot (with digital camera?) would be possible but rather incomplete. The serial console hack is not an option--these "modern" laptops doesn't come with serial ports anymore, and netconsole is a no-op at a so early point of the boot process. Or so I believe.

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

So something has broken on that non-preemptible critical section timing stuff since U4.

Hasn't anybody else stumbled on this?

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#186 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 9 lines · Rui Nuno Capela

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

So something has broken on that non-preemptible critical section timing stuff since U4.

Hasn't anybody else stumbled on this?

i'm using it myself and havent seen the problem yet. Could you send me the latest .configs, the working and the broken one too? I'll try to reprodue it (or maybe someone else with a serial console sees it too).

Ingo

#187 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 11 lines · Ingo Molnar
Quoted 8 lines · Rui Nuno Capela

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

So something has broken on that non-preemptible critical section timing stuff since U4.

Quoted 9 lines
Quoted 1 line

Hasn't anybody else stumbled on this?

i'm using it myself and havent seen the problem yet. Could you send me the latest .configs, the working and the broken one too? I'll try to reprodue it (or maybe someone else with a serial console sees it too).

Ingo

I am seeing something similar here with both U5 and U6 on both of my SMP systems (actually I haven't gotten to try U6 on my SMP system at home yet.) On my SMP system here (dual Xeon) I get a handful of traces during the boot and then the last thing I see is a trace that has something to do with parport, but the key MIGHT be that it always seems to crap out when I get traces for 3-level deep critical section nesting. I will try to capture the trace the old-fashioned way when I get a chance shortly.

I do have U5 booted on my UP system at home though.

kr

#188 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar
Quoted 1 line

Hasn't anybody else stumbled on this?

i'm using it myself and havent seen the problem yet. Could you send me the latest .configs, the working and the broken one too? I'll try to reprodue it (or maybe someone else with a serial console sees it too).

i found older .config's from you and i tried your desktop one and it didnt crash. But when i tried your laptop's U3 .config then i got the bootup crash immediately. Debugging it ...

Ingo

#189 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Ingo Molnar
Quoted 1 line

Hasn't anybody else stumbled on this?

Quoted 7 lines
Quoted 3 lines

i'm using it myself and havent seen the problem yet. Could you send me the latest .configs, the working and the broken one too? I'll try to reprodue it (or maybe someone else with a serial console sees it too).

i found older .config's from you and i tried your desktop one and it didnt crash. But when i tried your laptop's U3 .config then i got the bootup crash immediately. Debugging it ...

one difference in your config is that you have 4K stacks enabled. Could you disable them? Especially with rwsem-detection and tracing enabled the stack footprint can get pretty large ...

Ingo

#190 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 7 lines · Ingo Molnar
Quoted 3 lines

i found older .config's from you and i tried your desktop one and it didnt crash. But when i tried your laptop's U3 .config then i got the bootup crash immediately. Debugging it ...

one difference in your config is that you have 4K stacks enabled. Could you disable them? Especially with rwsem-detection and tracing enabled the stack footprint can get pretty large ...

indeed, this is what triggers with your .config:

testing NMI watchdog ... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
mcount: stack overflow: 1008

  [<c012cd9f>] ___trace+0x105/0x117
  [<c012cdd7>] __mcount+0x1d/0x1f
  [<c013e015>] cache_grow+0xe/0x1ab
  [<c013e3cd>] cache_alloc_refill+0x21b/0x253

enabling 8K stacks ought to help this one. I've made the limit a bit too conservative - there's still 1000 bytes left and the assert hits. Here's the full trace, the large footprint seems to be in zlib initialization:

mcount: stack overflow: 1008

 [<c012cd9f>] ___trace+0x105/0x117
 [<c012cdd7>] __mcount+0x1d/0x1f
 [<c013e015>] cache_grow+0xe/0x1ab
 [<c013e3cd>] cache_alloc_refill+0x21b/0x253
 [<c010efec>] mcount+0x14/0x18
 [<c013e015>] cache_grow+0xe/0x1ab
 [<c013e3cd>] cache_alloc_refill+0x21b/0x253
 [<c013e730>] __kmalloc+0x82/0x9f
 [<c03607c8>] malloc+0x1e/0x20
 [<c01008c9>] huft_build+0x309/0x5e8
 [<c0101bec>] inflate+0x4c/0xb0
 [<c010efec>] mcount+0x14/0x18
 [<c0101279>] inflate_fixed+0xcb/0x1a4
 [<c0101bec>] inflate+0x4c/0xb0
 [<c010efec>] mcount+0x14/0x18
 [<c0101eae>] gunzip+0x1d4/0x396
 [<c036130e>] unpack_to_rootfs+0x162/0x225
 [<c010efec>] mcount+0x14/0x18
 [<c0100434>] init+0x0/0x124
 [<c03613fe>] populate_rootfs+0x2d/0x3f
 [<c010046b>] init+0x37/0x124
 [<c0102365>] kernel_thread_helper+0x5/0xb

Ingo

#191 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 6 lines · Ingo Molnar

enabling 8K stacks ought to help this one. I've made the limit a bit too conservative - there's still 1000 bytes left and the assert hits. Here's the full trace, the large footprint seems to be in zlib initialization:

mcount: stack overflow: 1008

i've added a stackframe-size field to the end of every stack trace entry:

mcount: stack overflow: 1008

 [<c012cdaf>] ___trace+0x105/0x117 (12)
 [<c012cde7>] __mcount+0x1d/0x1f (32)
 [<c013e025>] cache_grow+0xe/0x1ab (4)
 [<c013e3dd>] cache_alloc_refill+0x21b/0x253 (4)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c013e025>] cache_grow+0xe/0x1ab (20)
 [<c013e3dd>] cache_alloc_refill+0x21b/0x253 (52)
 [<c013e740>] __kmalloc+0x82/0x9f (48)
 [<c03607c8>] malloc+0x1e/0x20 (28)
 [<c01008c9>] huft_build+0x309/0x5e8 (16)
 [<c0101bec>] inflate+0x4c/0xb0 (1444)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c0101279>] inflate_fixed+0xcb/0x1a4 (20)
 [<c0101bec>] inflate+0x4c/0xb0 (1212)
 [<c010effc>] mcount+0x14/0x18 (12)
 [<c0101eae>] gunzip+0x1d4/0x396 (20)
 [<c036130e>] unpack_to_rootfs+0x162/0x225 (28)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c0100434>] init+0x0/0x124 (4)
 [<c03613fe>] populate_rootfs+0x2d/0x3f (16)
 [<c010046b>] init+0x37/0x124 (20)
 [<c0102365>] kernel_thread_helper+0x5/0xb (20)

as suspected, zlib's huft_build() is fun:

lib/inflate.c:

  #define N_MAX 288       /* maximum number of codes in any set */

  STATIC int huft_build(
  ...
  {

unsigned v[N_MAX]; /* values in order of bit length */

a whopping 1152 bytes for this local variable alone! The patch below fixes this, but there are other overflows as well, later in the bootup.

Ingo

lib/inflate.c renamed from lib/inflate.c.orig +14 -3
@@ -300,7 +300,7 @@ STATIC int huft_build(
   register struct huft *q;      /* points to current table */
   struct huft r;                /* table entry for structure assignment */
   struct huft *u[BMAX];         /* table stack */
-  unsigned v[N_MAX];            /* values in order of bit length */
+  unsigned *v;                  /* values in order of bit length */
   register int w;               /* bits before this table == (l * h) */
   unsigned x[BMAX+1];           /* bit offsets, then code stack */
   unsigned *xp;                 /* pointer into x */
@@ -309,6 +309,10 @@ STATIC int huft_build(
 
 DEBG("huft1 ");
 
+  /* allocate new table */
+  v = (unsigned *)malloc(sizeof(unsigned)*N_MAX);
+  if (!v)
+    return 3;             /* not enough memory */
   /* Generate counts for each bit length */
   memzero(c, sizeof(c));
   p = b;  i = n;
@@ -322,6 +326,7 @@ DEBG("huft1 ");
   {
     *t = (struct huft *)NULL;
     *m = 0;
+    free(v);
     return 0;
   }
 
@@ -347,10 +352,14 @@ DEBG("huft3 ");
 
   /* Adjust last length count to fill out codes, if needed */
   for (y = 1 << j; j < i; j++, y <<= 1)
-    if ((y -= c[j]) < 0)
+    if ((y -= c[j]) < 0) {
+      free(v);
       return 2;                 /* bad input: more codes than bits */
-  if ((y -= c[i]) < 0)
+    }
+  if ((y -= c[i]) < 0) {
+    free(v);
     return 2;
+  }
   c[i] += y;
 
 DEBG("huft4 ");
@@ -422,6 +431,7 @@ DEBG1("3 ");
         {
           if (h)
             huft_free(u[0]);
+          free(v);
           return 3;             /* not enough memory */
         }
 DEBG1("4 ");
@@ -485,6 +495,7 @@ DEBG("h6f ");
 
 DEBG("huft7 ");
 
+  free(v);
   /* Return true (1) if we were given an incomplete table */
   return y != 0 && g != 1;
 }
#192 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Rui Nuno Capela
Quoted 18 lines · Rui Nuno Capela
Quoted 5 lines · Ingo Molnar
Quoted 4 lines

i have released the -U6 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

I'm experiencing terrible kernel panics at a very early bootstrap stage while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) -- (Ingo: this is about the very same trouble I've reported while pre-testing U6).

Sorry that I can't show any trace dumps; only a hard-screenshot (with digital camera?) would be possible but rather incomplete. The serial console hack is not an option--these "modern" laptops doesn't come with serial ports anymore, and netconsole is a no-op at a so early point of the boot process. Or so I believe.

Quoted 4 lines

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

Same here on al DELL P4/UP.

tglx

#193 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 6 lines · Thomas Gleixner
Quoted 6 lines

Sorry that I can't show any trace dumps; only a hard-screenshot (with digital camera?) would be possible but rather incomplete. The serial console hack is not an option--these "modern" laptops doesn't come with serial ports anymore, and netconsole is a no-op at a so early point of the boot process. Or so I believe.

Quoted 6 lines
Quoted 4 lines

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

Same here on al DELL P4/UP.

any chance for serial logging on that box?

and does this bootup crash go away if you unset PREEMPT_TIMING or LATENCY_TRACE, as suggested by Rui?

Ingo

#194 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 1 line · Ingo Molnar

any chance for serial logging on that box?

No

Quoted 2 lines

and does this bootup crash go away if you unset PREEMPT_TIMING or LATENCY_TRACE, as suggested by Rui?

It comes into init now, but dies when loading the AGP driver. Have to look into this.

tglx

#195 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 1 line · Thomas Gleixner

On Tue, 2004-10-19 at 17:57, Ingo Molnar wrote:

The laptop boots now. The culprits, which break the boot are:
pci-hotplug and firewire drivers.

agp loads correct.

No deeper insight yet.

The IPV6 code triggers the irqs_disabled() check in schedule. dmesg output attached.

tglx

0000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
On node 0 totalpages: 131023
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126927 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 DELL ) @ 0x000fdea0
ACPI: RSDT (v001 DELL CPi R 0x27d40113 ASL 0x00000061) @ 0x1fff0000
ACPI: FADT (v001 DELL CPi R 0x27d40113 ASL 0x00000061) @ 0x1fff0400
ACPI: MADT (v001 DELL CPi R 0x27d40113 ASL 0x00000047) @ 0x1fff0c00
ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hdc6 ro
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3056.985 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515412k/524092k available (1776k kernel code, 8124k reserved, 811k data, 148k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 6062.08 BogoMIPS (lpj=3031040)
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
CPU: Intel Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfcf1e, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xe2f4, dseg 0x40
PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
pnp: 00:01: ioport range 0x1000-0x105f could not be reserved
pnp: 00:01: ioport range 0x1060-0x107f has been reserved
pnp: 00:01: ioport range 0x1080-0x10bf has been reserved
pnp: 00:01: ioport range 0x10c0-0x10ff could not be reserved
pnp: 00:01: ioport range 0xf400-0xf4fe has been reserved
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch ([email protected])
devfs: boot_options: 0x0
Initializing Cryptographic API
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
i8042.c: Can't read CTR while initializing i8042.
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 17 (level, low) -> IRQ 17
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 16
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio

Probing IDE interface ide0...
hda: HL-DT-STCD-RW/DVD-ROM GCC-4241N, ATAPI CD/DVD-ROM drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: IC25N040ATMR04-0, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hdc: max request size: 1024KiB
hdc: 78140160 sectors (40007 MB) w/1740KiB Cache, CHS=16383/255/63, UDMA(100)
hdc: cache flushes supported
/dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 >
NET: Registered protocol family 2
IP: routing cache hash table of 64 buckets, 18Kbytes
TCP: Hash tables configured (established 512 bind 923)
NET: Registered protocol family 8
NET: Registered protocol family 20
ACPI: (supports S0 S1 S3 S4 S4bios S5)
ACPI wakeup devices:
LID PBTN PCI0 USB0 USB1 USB2 USB3 MODM PCIE
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
EXT3-fs: recovery complete.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 148k freed
NET: Registered protocol family 1
EXT3 FS on hdc6, internal journal
Real Time Clock Driver v1.12
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
b44.c:v0.95 (Aug 3, 2004)
ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 17 (level, low) -> IRQ 17
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0d:56:39:10:9e
device-mapper: 4.1.0-ioctl (2003-12-10) initialised: [email protected]
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49346 usecs
intel8x0: clocking to 48000
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xf4fffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
PCI: Enabling device 0000:02:04.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:02:04.0[A] -> GSI 16 (level, low) -> IRQ 16
Yenta: CardBus bridge found at 0000:02:04.0 [1028:015f]
Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
Socket status: 30000006
input: PC Speaker
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 16, io base 0xbf80
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0xbf40
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0xbf20
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
usb 2-1: new low speed USB device using address 2
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new driver hiddev
input: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1
usbcore: registered new driver usbhid /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
hw_random: RNG not detected
Intel 810 + AC97 Audio, version 1.01, 18:13:38 Oct 19 2004
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.6 to 64
MC'97 1 converters and GPIO not ready (0xff00)
b44: eth0: Link is down.
NET: Registered protocol family 17
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is on for TX and on for RX.
Capability LSM initialized
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0353400(lo)

BUG: sleeping function called from invalid context modprobe(3296) at /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/lib/rwsem-generic.c:313
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02bac00>] down_read+0x1b/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b3303>] addrconf_dst_alloc+0x164/0x17a [ipv6]
 [<e09aa7ee>] ipv6_add_addr+0xbf/0x26a [ipv6]
 [<e09acd8b>] init_loopback+0x59/0x10f [ipv6]
 [<e09ad220>] addrconf_notify+0xfa/0x190 [ipv6]
 [<c0129358>] notifier_chain_register+0x44/0x4c
 [<c0257160>] register_netdevice_notifier+0x6c/0x6e
 [<e08a830c>] addrconf_init+0xf/0x81 [ipv6]
 [<e08a81c6>] inet6_init+0x13c/0x203 [ipv6]
 [<c0134ee1>] sys_init_module+0x17a/0x227
 [<c01060df>] syscall_call+0x7/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0) .. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: modprobe/0x04000001/3296
caller is cond_resched+0x58/0x73
 [<c02ba15e>] __sched_text_start+0x56e/0x5be
 [<c02ba833>] cond_resched+0x58/0x73
 [<c0106ee5>] dump_stack+0x1c/0x20
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02ba833>] cond_resched+0x58/0x73
 [<c02bac05>] down_read+0x20/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b3303>] addrconf_dst_alloc+0x164/0x17a [ipv6]
 [<e09aa7ee>] ipv6_add_addr+0xbf/0x26a [ipv6]
 [<e09acd8b>] init_loopback+0x59/0x10f [ipv6]
 [<e09ad220>] addrconf_notify+0xfa/0x190 [ipv6]
 [<c0129358>] notifier_chain_register+0x44/0x4c
 [<c0257160>] register_netdevice_notifier+0x6c/0x6e
 [<e08a830c>] addrconf_init+0xf/0x81 [ipv6]
 [<e08a81c6>] inet6_init+0x13c/0x203 [ipv6]
 [<c0134ee1>] sys_init_module+0x17a/0x227
 [<c01060df>] syscall_call+0x7/0xb

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0) .. entry 2: print_traces+0x17/0x50 / (0x0)

IPv6 over IPv4 tunneling driver
apm: BIOS not found.
lp: driver loaded but no devices found

BUG: sleeping function called from invalid context ksoftirqd/0(2) at /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/lib/rwsem-generic.c:313
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02bac00>] down_read+0x1b/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b1eb7>] ndisc_dst_alloc+0x130/0x13a [ipv6]
 [<e09b7b5d>] ndisc_send_rs+0x95/0x4bf [ipv6]
 [<e09a6d7f>] ip6_output+0x0/0x44 [ipv6]
 [<e09b56f4>] fib6_prune_clones+0x27/0x2b [ipv6]
 [<e09ada6b>] addrconf_dad_completed+0xa0/0xe9 [ipv6]
 [<e09ad90f>] addrconf_dad_timer+0x37/0xf3 [ipv6]
 [<c0118e4b>] __wake_up+0x59/0x85
 [<e09ad8d8>] addrconf_dad_timer+0x0/0xf3 [ipv6]
 [<c0125414>] run_timer_softirq+0x11f/0x2db
 [<c01216a9>] ___do_softirq+0x79/0xbc
 [<c01219be>] ksoftirqd+0x0/0xc8
 [<c0121774>] _do_softirq+0x17/0x19
 [<c0121a49>] ksoftirqd+0x8b/0xc8
 [<c0130129>] kthread+0xa5/0xab
 [<c0130084>] kthread+0x0/0xab
 [<c0104285>] kernel_thread_helper+0x5/0xb

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0) .. entry 2: print_traces+0x17/0x50 / (0x0)

Installing knfsd (copyright (C) 1996 [email protected]).
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x807
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0a00-0x0aff: clean.
apm: BIOS not found.
eth0: no IPv6 routers present
apm: BIOS not found. /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-input.c: event field not found /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-input.c: event field not found

#196 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 2 lines · Thomas Gleixner

The IPV6 code triggers the irqs_disabled() check in schedule. dmesg output attached.

ok, does the patch below, ontop of -U7, fix them?

Ingo

include/net/protocol.h +1 -0
@@ -83,6 +83,7 @@ extern spinlock_t inet_proto_lock;
 
 #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
 extern struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
+extern rwlock_t inet6_proto_lock;
 #endif
 
 extern int	inet_add_protocol(struct net_protocol *prot, unsigned char num);
net/ipv6/af_inet6.c +8 -8
@@ -94,7 +94,7 @@ atomic_t inet6_sock_nr;
  * build a new socket.
  */
 static struct list_head inetsw6[SOCK_MAX];
-static spinlock_t inetsw6_lock = SPIN_LOCK_UNLOCKED;
+static rwlock_t inetsw6_lock = RW_LOCK_UNLOCKED;
 
 static void inet6_sock_destruct(struct sock *sk)
 {
@@ -127,7 +127,7 @@ static int inet6_create(struct socket *s
 
 	/* Look for the requested type/protocol pair. */
 	answer = NULL;
-	rcu_read_lock();
+	rcu_read_lock_read(&inetsw6_lock);
 	list_for_each_rcu(p, &inetsw6[sock->type]) {
 		answer = list_entry(p, struct inet_protosw, list);
 
@@ -162,7 +162,7 @@ static int inet6_create(struct socket *s
 	answer_prot = answer->prot;
 	answer_no_check = answer->no_check;
 	answer_flags = answer->flags;
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 
 	BUG_TRAP(answer_prot->slab != NULL);
 
@@ -242,7 +242,7 @@ static int inet6_create(struct socket *s
 out:
 	return rc;
 out_rcu_unlock:
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 	goto out;
 }
 
@@ -542,7 +542,7 @@ inet6_register_protosw(struct inet_proto
 	int protocol = p->protocol;
 	struct list_head *last_perm;
 
-	spin_lock_bh(&inetsw6_lock);
+	write_lock_bh(&inetsw6_lock);
 
 	if (p->type >= SOCK_MAX)
 		goto out_illegal;
@@ -573,7 +573,7 @@ inet6_register_protosw(struct inet_proto
 	 */
 	list_add_rcu(&p->list, last_perm);
 out:
-	spin_unlock_bh(&inetsw6_lock);
+	write_unlock_bh(&inetsw6_lock);
 	return;
 
 out_permanent:
@@ -596,9 +596,9 @@ inet6_unregister_protosw(struct inet_pro
 		       "Attempt to unregister permanent protocol %d.\n",
 		       p->protocol);
 	} else {
-		spin_lock_bh(&inetsw6_lock);
+		write_lock_bh(&inetsw6_lock);
 		list_del_rcu(&p->list);
-		spin_unlock_bh(&inetsw6_lock);
+		write_unlock_bh(&inetsw6_lock);
 
 		synchronize_net();
 	}
net/ipv6/icmp.c +2 -2
@@ -537,11 +537,11 @@ static void icmpv6_notify(struct sk_buff
 
 	hash = nexthdr & (MAX_INET_PROTOS - 1);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&inet6_proto_lock);
 	ipprot = rcu_dereference(inet6_protos[hash]);
 	if (ipprot && ipprot->err_handler)
 		ipprot->err_handler(skb, NULL, type, code, inner_offset, info);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inet6_proto_lock);
 
 	read_lock(&raw_v6_lock);
 	if ((sk = sk_head(&raw_v6_htable[hash])) != NULL) {
net/ipv6/ip6_input.c +3 -3
@@ -156,7 +156,7 @@ static inline int ip6_input_finish(struc
 		skb->h.raw += (skb->h.raw[1]+1)<<3;
 	}
 
-	rcu_read_lock();
+	rcu_read_lock_read(&raw_v6_lock);
 resubmit:
 	if (!pskb_pull(skb, skb->h.raw - skb->data))
 		goto discard;
@@ -205,12 +205,12 @@ resubmit:
 			kfree_skb(skb);
 		}
 	}
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	return 0;
 
 discard:
 	IP6_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	kfree_skb(skb);
 	return 0;
 }
net/ipv6/ndisc.c +3 -3
@@ -289,17 +289,17 @@ static int ndisc_constructor(struct neig
 	struct neigh_parms *parms;
 	int is_multicast = ipv6_addr_is_multicast(addr);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&addrconf_lock);
 	in6_dev = in6_dev_get(dev);
 	if (in6_dev == NULL) {
-		rcu_read_unlock();
+		rcu_read_unlock_read(&addrconf_lock);
 		return -EINVAL;
 	}
 
 	parms = in6_dev->nd_parms;
 	__neigh_parms_put(neigh->parms);
 	neigh->parms = neigh_parms_clone(parms);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&addrconf_lock);
 
 	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
 	if (dev->hard_header == NULL) {
net/ipv6/protocol.c +5 -5
@@ -40,14 +40,14 @@
 #include <net/protocol.h>
 
 struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
-static spinlock_t inet6_proto_lock = SPIN_LOCK_UNLOCKED;
+rwlock_t inet6_proto_lock = RW_LOCK_UNLOCKED;
 
 
 int inet6_add_protocol(struct inet6_protocol *prot, unsigned char protocol)
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash]) {
 		ret = -1;
@@ -56,7 +56,7 @@ int inet6_add_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	return ret;
 }
@@ -69,7 +69,7 @@ int inet6_del_protocol(struct inet6_prot
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash] != prot) {
 		ret = -1;
@@ -78,7 +78,7 @@ int inet6_del_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	synchronize_net();
 
#197 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 6 lines · Ingo Molnar
Quoted 2 lines · Thomas Gleixner

The IPV6 code triggers the irqs_disabled() check in schedule. dmesg output attached.

ok, does the patch below, ontop of -U7, fix them?

Yes, it does. Thanks.

tglx

Quoted 189 lines
include/net/protocol.h +1 -0
@@ -83,6 +83,7 @@ extern spinlock_t inet_proto_lock;
 
 #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
 extern struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
+extern rwlock_t inet6_proto_lock;
 #endif
 
 extern int	inet_add_protocol(struct net_protocol *prot, unsigned char num);
net/ipv6/af_inet6.c +8 -8
@@ -94,7 +94,7 @@ atomic_t inet6_sock_nr;
  * build a new socket.
  */
 static struct list_head inetsw6[SOCK_MAX];
-static spinlock_t inetsw6_lock = SPIN_LOCK_UNLOCKED;
+static rwlock_t inetsw6_lock = RW_LOCK_UNLOCKED;
 
 static void inet6_sock_destruct(struct sock *sk)
 {
@@ -127,7 +127,7 @@ static int inet6_create(struct socket *s
 
 	/* Look for the requested type/protocol pair. */
 	answer = NULL;
-	rcu_read_lock();
+	rcu_read_lock_read(&inetsw6_lock);
 	list_for_each_rcu(p, &inetsw6[sock->type]) {
 		answer = list_entry(p, struct inet_protosw, list);
 
@@ -162,7 +162,7 @@ static int inet6_create(struct socket *s
 	answer_prot = answer->prot;
 	answer_no_check = answer->no_check;
 	answer_flags = answer->flags;
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 
 	BUG_TRAP(answer_prot->slab != NULL);
 
@@ -242,7 +242,7 @@ static int inet6_create(struct socket *s
 out:
 	return rc;
 out_rcu_unlock:
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 	goto out;
 }
 
@@ -542,7 +542,7 @@ inet6_register_protosw(struct inet_proto
 	int protocol = p->protocol;
 	struct list_head *last_perm;
 
-	spin_lock_bh(&inetsw6_lock);
+	write_lock_bh(&inetsw6_lock);
 
 	if (p->type >= SOCK_MAX)
 		goto out_illegal;
@@ -573,7 +573,7 @@ inet6_register_protosw(struct inet_proto
 	 */
 	list_add_rcu(&p->list, last_perm);
 out:
-	spin_unlock_bh(&inetsw6_lock);
+	write_unlock_bh(&inetsw6_lock);
 	return;
 
 out_permanent:
@@ -596,9 +596,9 @@ inet6_unregister_protosw(struct inet_pro
 		       "Attempt to unregister permanent protocol %d.\n",
 		       p->protocol);
 	} else {
-		spin_lock_bh(&inetsw6_lock);
+		write_lock_bh(&inetsw6_lock);
 		list_del_rcu(&p->list);
-		spin_unlock_bh(&inetsw6_lock);
+		write_unlock_bh(&inetsw6_lock);
 
 		synchronize_net();
 	}
net/ipv6/icmp.c +2 -2
@@ -537,11 +537,11 @@ static void icmpv6_notify(struct sk_buff
 
 	hash = nexthdr & (MAX_INET_PROTOS - 1);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&inet6_proto_lock);
 	ipprot = rcu_dereference(inet6_protos[hash]);
 	if (ipprot && ipprot->err_handler)
 		ipprot->err_handler(skb, NULL, type, code, inner_offset, info);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inet6_proto_lock);
 
 	read_lock(&raw_v6_lock);
 	if ((sk = sk_head(&raw_v6_htable[hash])) != NULL) {
net/ipv6/ip6_input.c +3 -3
@@ -156,7 +156,7 @@ static inline int ip6_input_finish(struc
 		skb->h.raw += (skb->h.raw[1]+1)<<3;
 	}
 
-	rcu_read_lock();
+	rcu_read_lock_read(&raw_v6_lock);
 resubmit:
 	if (!pskb_pull(skb, skb->h.raw - skb->data))
 		goto discard;
@@ -205,12 +205,12 @@ resubmit:
 			kfree_skb(skb);
 		}
 	}
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	return 0;
 
 discard:
 	IP6_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	kfree_skb(skb);
 	return 0;
 }
net/ipv6/ndisc.c +3 -3
@@ -289,17 +289,17 @@ static int ndisc_constructor(struct neig
 	struct neigh_parms *parms;
 	int is_multicast = ipv6_addr_is_multicast(addr);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&addrconf_lock);
 	in6_dev = in6_dev_get(dev);
 	if (in6_dev == NULL) {
-		rcu_read_unlock();
+		rcu_read_unlock_read(&addrconf_lock);
 		return -EINVAL;
 	}
 
 	parms = in6_dev->nd_parms;
 	__neigh_parms_put(neigh->parms);
 	neigh->parms = neigh_parms_clone(parms);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&addrconf_lock);
 
 	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
 	if (dev->hard_header == NULL) {
net/ipv6/protocol.c +5 -5
@@ -40,14 +40,14 @@
 #include <net/protocol.h>
 
 struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
-static spinlock_t inet6_proto_lock = SPIN_LOCK_UNLOCKED;
+rwlock_t inet6_proto_lock = RW_LOCK_UNLOCKED;
 
 
 int inet6_add_protocol(struct inet6_protocol *prot, unsigned char protocol)
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash]) {
 		ret = -1;
@@ -56,7 +56,7 @@ int inet6_add_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	return ret;
 }
@@ -69,7 +69,7 @@ int inet6_del_protocol(struct inet6_prot
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash] != prot) {
 		ret = -1;
@@ -78,7 +78,7 @@ int inet6_del_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	synchronize_net();
 
#198 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Rui Nuno Capela
Quoted 4 lines · On Tue, 19 Oct 2004 16:23:49 +0100 (WEST) "Rui Nuno Capela" <[email protected]>…

I'm experiencing terrible kernel panics at a very early bootstrap stage while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) -- (Ingo: this is about the very same trouble I've reported while pre-testing U6).

[..]

Quoted 9 lines

OK. After some incremental configurations, I've isolated that those oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the case.

So something has broken on that non-preemptible critical section timing stuff since U4.

Hasn't anybody else stumbled on this?

I don't get any oopses or panics, but i can observer a rather interesting behaviour. When i enable the latency traces via

echo 1 > /proc/sys/kernel/trace_enabled

my machine starts to make little pauses of ca 3-4 secs. X "hangs" for this duration and so does aplay when playing a .wav file. "hangs" means that the X display seems to be locked. Interestingly enough all keystrokes i entered during the "hang" seem to arrive fine after the hang has ended. aplay experiences an xrun.

jackd OTOH is not affected (probably since it runs SCHED_FIFO). I can happily continue noodling with my guitar through jackd and jack-rack..

But besides that it runs fine here. I get some fairly long non preemptible critical sections reports though.

here's one (i snipped off quite a few in the middle to make the email smaller):

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
latency: 1841 us, entries: 4000 (12990) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]

    -----------------
    | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------

=> started at: __schedule+0x3b/0x5d0 <c02a767b>
=> ended at: finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
00000001 0.000ms (+0.000ms): __schedule (ksoftirqd) 00000001 0.000ms (+0.000ms): sched_clock (__schedule) 00000002 0.000ms (+0.000ms): deactivate_task (__schedule) 00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task) 04000002 0.000ms (+0.000ms): __switch_to (__schedule) 04000002 0.001ms (+0.000ms): finish_task_switch (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.001ms (+0.000ms): sched_clock (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.002ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write) 04000000 0.002ms (+0.000ms): __schedule (down_write) 04000001 0.002ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write) 04000000 0.002ms (+0.000ms): __schedule (down_write) 04000001 0.003ms (+0.000ms): sched_clock (__schedule) 04000000 0.003ms (+0.000ms): schedule (down_write) 04000000 0.003ms (+0.000ms): __schedule (down_write) 04000001 0.003ms (+0.000ms): sched_clock (__schedule) 04000000 0.003ms (+0.000ms): schedule (down_write) 04000000 0.003ms (+0.000ms): __schedule (down_write) 04000001 0.003ms (+0.000ms): sched_clock (__schedule) 04000000 0.004ms (+0.000ms): schedule (down_write) 04000000 0.004ms (+0.000ms): __schedule (down_write) 04000001 0.004ms (+0.000ms): sched_clock (__schedule) 04000000 0.004ms (+0.000ms): schedule (down_write) 04000000 0.004ms (+0.000ms): __schedule (down_write) 04000001 0.004ms (+0.000ms): sched_clock (__schedule) 04000000 0.005ms (+0.000ms): schedule (down_write) 04000000 0.005ms (+0.000ms): __schedule (down_write) 04000001 0.005ms (+0.000ms): sched_clock (__schedule) 04000000 0.005ms (+0.000ms): schedule (down_write) 04000000 0.005ms (+0.000ms): __schedule (down_write) 04000001 0.005ms (+0.000ms): sched_clock (__schedule) 04000000 0.006ms (+0.000ms): schedule (down_write) 04000000 0.006ms (+0.000ms): __schedule (down_write) 04000001 0.006ms (+0.000ms): sched_clock (__schedule) 04000000 0.006ms (+0.000ms): schedule (down_write) 04000000 0.006ms (+0.000ms): __schedule (down_write) 04000001 0.006ms (+0.000ms): sched_clock (__schedule) 04000000 0.006ms (+0.000ms): schedule (down_write) 04000000 0.007ms (+0.000ms): __schedule (down_write) 04000001 0.007ms (+0.000ms): sched_clock (__schedule) 04000000 0.007ms (+0.000ms): schedule (down_write) 04000000 0.007ms (+0.000ms): __schedule (down_write) 04000001 0.007ms (+0.000ms): sched_clock (__schedule) 04000000 0.007ms (+0.000ms): schedule (down_write) 04000000 0.007ms (+0.000ms): __schedule (down_write) 04000001 0.008ms (+0.000ms): sched_clock (__schedule) 04000000 0.008ms (+0.000ms): schedule (down_write) 04000000 0.008ms (+0.000ms): __schedule (down_write) 04000001 0.008ms (+0.000ms): sched_clock (__schedule) 04000000 0.008ms (+0.000ms): schedule (down_write) 04000000 0.008ms (+0.000ms): __schedule (down_write) 04000001 0.009ms (+0.000ms): sched_clock (__schedule) 04000000 0.009ms (+0.000ms): schedule (down_write) 04000000 0.009ms (+0.000ms): __schedule (down_write) 04000001 0.009ms (+0.000ms): sched_clock (__schedule) 04000000 0.009ms (+0.000ms): schedule (down_write) 04000000 0.009ms (+0.000ms): __schedule (down_write) 04000001 0.009ms (+0.000ms): sched_clock (__schedule) 04000000 0.010ms (+0.000ms): schedule (down_write) 04000000 0.010ms (+0.000ms): __schedule (down_write) 04000001 0.010ms (+0.000ms): sched_clock (__schedule) 04000000 0.010ms (+0.000ms): schedule (down_write) 04000000 0.010ms (+0.000ms): __schedule (down_write) 04000001 0.010ms (+0.000ms): sched_clock (__schedule) 04000000 0.011ms (+0.000ms): schedule (down_write) 04000000 0.011ms (+0.000ms): __schedule (down_write) 04000001 0.011ms (+0.000ms): sched_clock (__schedule) 04000000 0.011ms (+0.000ms): schedule (down_write) 04000000 0.011ms (+0.000ms): __schedule (down_write) 04000001 0.011ms (+0.000ms): sched_clock (__schedule) 04000000 0.012ms (+0.000ms): schedule (down_write) 04000000 0.012ms (+0.000ms): __schedule (down_write) 04000001 0.012ms (+0.000ms): sched_clock (__schedule) 04000000 0.012ms (+0.000ms): schedule (down_write) 04000000 0.012ms (+0.000ms): __schedule (down_write) 04000001 0.012ms (+0.000ms): sched_clock (__schedule) 04000000 0.012ms (+0.000ms): schedule (down_write) 04000000 0.013ms (+0.000ms): __schedule (down_write) 04000001 0.013ms (+0.000ms): sched_clock (__schedule) 04000000 0.013ms (+0.000ms): schedule (down_write) 04000000 0.013ms (+0.000ms): __schedule (down_write) 04000001 0.013ms (+0.000ms): sched_clock (__schedule) 04000000 0.013ms (+0.000ms): schedule (down_write) 04000000 0.013ms (+0.000ms): __schedule (down_write) 04000001 0.014ms (+0.000ms): sched_clock (__schedule) 04000000 0.014ms (+0.000ms): schedule (down_write) 04000000 0.014ms (+0.000ms): __schedule (down_write) 04000001 0.014ms (+0.000ms): sched_clock (__schedule) 04000000 0.014ms (+0.000ms): schedule (down_write) 04000000 0.014ms (+0.000ms): __schedule (down_write) 04000001 0.014ms (+0.000ms): sched_clock (__schedule) 04000000 0.015ms (+0.000ms): schedule (down_write) 04000000 0.015ms (+0.000ms): __schedule (down_write) 04000001 0.015ms (+0.000ms): sched_clock (__schedule) 04000000 0.015ms (+0.000ms): schedule (down_write) 04000000 0.015ms (+0.000ms): __schedule (down_write) 04000001 0.015ms (+0.000ms): sched_clock (__schedule) 04000000 0.016ms (+0.000ms): schedule (down_write) 04000000 0.016ms (+0.000ms): __schedule (down_write) 04000001 0.016ms (+0.000ms): sched_clock (__schedule) 04000000 0.016ms (+0.000ms): schedule (down_write) 04000000 0.016ms (+0.000ms): __schedule (down_write) 04000001 0.016ms (+0.000ms): sched_clock (__schedule) 04000000 0.017ms (+0.000ms): schedule (down_write) 04000000 0.017ms (+0.000ms): __schedule (down_write) 04000001 0.017ms (+0.000ms): sched_clock (__schedule) 04000000 0.017ms (+0.000ms): schedule (down_write) 04000000 0.017ms (+0.000ms): __schedule (down_write) 04000001 0.017ms (+0.000ms): sched_clock (__schedule) 04000000 0.018ms (+0.000ms): schedule (down_write) 04000000 0.018ms (+0.000ms): __schedule (down_write) 04000001 0.018ms (+0.000ms): sched_clock (__schedule) 04000000 0.018ms (+0.000ms): schedule (down_write) 04000000 0.018ms (+0.000ms): __schedule (down_write) 04000001 0.018ms (+0.000ms): sched_clock (__schedule) 04000000 0.018ms (+0.000ms): schedule (down_write) 04000000 0.019ms (+0.000ms): __schedule (down_write) 04000001 0.019ms (+0.000ms): sched_clock (__schedule) 04000000 0.019ms (+0.000ms): schedule (down_write) 04000000 0.019ms (+0.000ms): __schedule (down_write) 04000001 0.019ms (+0.000ms): sched_clock (__schedule) 04000000 0.019ms (+0.000ms): schedule (down_write) 04000000 0.019ms (+0.000ms): __schedule (down_write) 04000001 0.020ms (+0.000ms): sched_clock (__schedule) 04000000 0.020ms (+0.000ms): schedule (down_write) 04000000 0.020ms (+0.000ms): __schedule (down_write) 04000001 0.020ms (+0.000ms): sched_clock (__schedule) 04000000 0.020ms (+0.000ms): schedule (down_write) 04000000 0.020ms (+0.000ms): __schedule (down_write) 04000001 0.020ms (+0.000ms): sched_clock (__schedule) 04000000 0.021ms (+0.000ms): schedule (down_write) 04000000 0.021ms (+0.000ms): __schedule (down_write) 04000001 0.021ms (+0.000ms): sched_clock (__schedule) 04000000 0.021ms (+0.000ms): schedule (down_write) 04000000 0.021ms (+0.000ms): __schedule (down_write) 04000001 0.021ms (+0.000ms): sched_clock (__schedule) 04000000 0.022ms (+0.000ms): schedule (down_write) 04000000 0.022ms (+0.000ms): __schedule (down_write) 04000001 0.022ms (+0.000ms): sched_clock (__schedule) 04000000 0.022ms (+0.000ms): schedule (down_write) 04000000 0.022ms (+0.000ms): __schedule (down_write) 04000001 0.022ms (+0.000ms): sched_clock (__schedule) 04000000 0.023ms (+0.000ms): schedule (down_write) 04000000 0.023ms (+0.000ms): __schedule (down_write) 04000001 0.023ms (+0.000ms): sched_clock (__schedule) 04000000 0.023ms (+0.000ms): schedule (down_write) 04000000 0.023ms (+0.000ms): __schedule (down_write) 04000001 0.023ms (+0.000ms): sched_clock (__schedule) 04000000 0.023ms (+0.000ms): schedule (down_write) 04000000 0.024ms (+0.000ms): __schedule (down_write) 04000001 0.024ms (+0.000ms): sched_clock (__schedule) 04000000 0.024ms (+0.000ms): schedule (down_write) 04000000 0.024ms (+0.000ms): __schedule (down_write) 04000001 0.024ms (+0.000ms): sched_clock (__schedule) 04000000 0.024ms (+0.000ms): schedule (down_write) 04000000 0.025ms (+0.000ms): __schedule (down_write) 04000001 0.025ms (+0.000ms): sched_clock (__schedule) 04000000 0.025ms (+0.000ms): schedule (down_write) 04000000 0.025ms (+0.000ms): __schedule (down_write) 04000001 0.025ms (+0.000ms): sched_clock (__schedule) 04000000 0.025ms (+0.000ms): schedule (down_write) 04000000 0.025ms (+0.000ms): __schedule (down_write) 04000001 0.026ms (+0.000ms): sched_clock (__schedule) 04000000 0.026ms (+0.000ms): schedule (down_write) 04000000 0.026ms (+0.000ms): __schedule (down_write) 04000001 0.026ms (+0.000ms): sched_clock (__schedule) 04000000 0.026ms (+0.000ms): schedule (down_write) 04000000 0.026ms (+0.000ms): __schedule (down_write) 04000001 0.026ms (+0.000ms): sched_clock (__schedule) 04000000 0.027ms (+0.000ms): schedule (down_write) 04000000 0.027ms (+0.000ms): __schedule (down_write) 04000001 0.027ms (+0.000ms): sched_clock (__schedule) 04000000 0.027ms (+0.000ms): schedule (down_write) 04000000 0.027ms (+0.000ms): __schedule (down_write) 04000001 0.027ms (+0.000ms): sched_clock (__schedule) 04000000 0.028ms (+0.000ms): schedule (down_write) 04000000 0.028ms (+0.000ms): __schedule (down_write) 04000001 0.028ms (+0.000ms): sched_clock (__schedule) 04000000 0.028ms (+0.000ms): schedule (down_write) 04000000 0.028ms (+0.000ms): __schedule (down_write) 04000001 0.028ms (+0.000ms): sched_clock (__schedule) 04000000 0.029ms (+0.000ms): schedule (down_write) 04000000 0.029ms (+0.000ms): __schedule (down_write) 04000001 0.029ms (+0.000ms): sched_clock (__schedule) 04000000 0.029ms (+0.000ms): schedule (down_write) 04000000 0.029ms (+0.000ms): __schedule (down_write) 04000001 0.029ms (+0.000ms): sched_clock (__schedule) 04000000 0.029ms (+0.000ms): schedule (down_write) 04000000 0.030ms (+0.000ms): __schedule (down_write) 04000001 0.030ms (+0.000ms): sched_clock (__schedule) 04000000 0.030ms (+0.000ms): schedule (down_write) 04000000 0.030ms (+0.000ms): __schedule (down_write) 04000001 0.030ms (+0.000ms): sched_clock (__schedule) 04000000 0.030ms (+0.000ms): schedule (down_write) 04000000 0.030ms (+0.000ms): __schedule (down_write) 04000001 0.031ms (+0.000ms): sched_clock (__schedule) 04000000 0.031ms (+0.000ms): schedule (down_write) 04000000 0.031ms (+0.000ms): __schedule (down_write) 04000001 0.031ms (+0.000ms): sched_clock (__schedule) 04000000 0.031ms (+0.000ms): schedule (down_write) 04000000 0.031ms (+0.000ms): __schedule (down_write) 04000001 0.031ms (+0.000ms): sched_clock (__schedule) 04000000 0.032ms (+0.000ms): schedule (down_write) 04000000 0.032ms (+0.000ms): __schedule (down_write) 04000001 0.032ms (+0.000ms): sched_clock (__schedule) 04000000 0.032ms (+0.000ms): schedule (down_write) 04000000 0.032ms (+0.000ms): __schedule (down_write) 04000001 0.032ms (+0.000ms): sched_clock (__schedule) 04000000 0.033ms (+0.000ms): schedule (down_write) 04000000 0.033ms (+0.000ms): __schedule (down_write) 04000001 0.033ms (+0.000ms): sched_clock (__schedule) 04000000 0.033ms (+0.000ms): schedule (down_write) 04000000 0.033ms (+0.000ms): __schedule (down_write) 04000001 0.033ms (+0.000ms): sched_clock (__schedule) 04000000 0.034ms (+0.000ms): schedule (down_write) 04000000 0.034ms (+0.000ms): __schedule (down_write) 04000001 0.034ms (+0.000ms): sched_clock (__schedule) 04000000 0.034ms (+0.000ms): schedule (down_write) 04000000 0.034ms (+0.000ms): __schedule (down_write) 04000001 0.034ms (+0.000ms): sched_clock (__schedule) 04000000 0.035ms (+0.000ms): schedule (down_write) 04000000 0.035ms (+0.000ms): __schedule (down_write) 04000001 0.035ms (+0.000ms): sched_clock (__schedule) 04000000 0.035ms (+0.000ms): schedule (down_write) 04000000 0.035ms (+0.000ms): __schedule (down_write) 04000001 0.035ms (+0.000ms): sched_clock (__schedule) 04000000 0.035ms (+0.000ms): schedule (down_write) 04000000 0.036ms (+0.000ms): __schedule (down_write)

[...many many more of similar ones...]

04000000 0.554ms (+0.000ms): __schedule (down_write) 04000001 0.554ms (+0.000ms): sched_clock (__schedule) 04000000 0.554ms (+0.000ms): schedule (down_write) 04000000 0.554ms (+0.000ms): __schedule (down_write) 04000001 0.554ms (+0.000ms): sched_clock (__schedule) 04000000 0.555ms (+0.000ms): schedule (down_write) 04000000 0.555ms (+0.000ms): __schedule (down_write) 04000001 0.555ms (+0.000ms): sched_clock (__schedule) 04000000 0.555ms (+0.000ms): schedule (down_write) 04000000 0.555ms (+0.000ms): __schedule (down_write) 04000001 0.555ms (+0.000ms): sched_clock (__schedule) 04000000 0.555ms (+0.000ms): schedule (down_write) 04000000 0.556ms (+0.000ms): __schedule (down_write) 04000001 0.556ms (+0.000ms): sched_clock (__schedule) 04000000 0.556ms (+0.000ms): schedule (down_write) 04000000 0.556ms (+0.000ms): __schedule (down_write) 04000001 0.556ms (+0.000ms): sched_clock (__schedule) 04000000 0.556ms (+0.000ms): schedule (down_write) 04000000 0.556ms (+0.000ms): __schedule (down_write) 04000001 0.557ms (+0.000ms): sched_clock (__schedule) 04000000 0.557ms (+0.000ms): schedule (down_write) 04000000 0.557ms (+0.000ms): __schedule (down_write) 04000001 0.557ms (+0.000ms): sched_clock (__schedule) 04000000 0.557ms (+0.000ms): schedule (down_write) 04000000 0.557ms (+0.000ms): __schedule (down_write) 04000001 0.557ms (+0.000ms): sched_clock (__schedule) 04000000 0.558ms (+0.000ms): schedule (down_write) 04000000 0.558ms (+0.000ms): __schedule (down_write) 04000001 0.558ms (+0.000ms): sched_clock (__schedule) 04000000 0.558ms (+0.000ms): schedule (down_write) 04000000 0.558ms (+0.000ms): __schedule (down_write) 04000001 0.558ms (+0.000ms): sched_clock (__schedule) 04000000 0.559ms (+0.000ms): schedule (down_write) 04000000 0.559ms (+0.000ms): __schedule (down_write) 04000001 0.559ms (+0.000ms): sched_clock (__schedule) 04000000 0.559ms (+0.000ms): schedule (down_write) 04000000 0.559ms (+0.000ms): __schedule (down_write) 04000001 0.559ms (+0.000ms): sched_clock (__schedule) 04000000 0.560ms (+0.000ms): schedule (down_write) 04000000 0.560ms (+0.000ms): __schedule (down_write) 04000001 0.560ms (+0.000ms): sched_clock (__schedule) 04000000 0.560ms (+0.000ms): schedule (down_write) 04000000 0.560ms (+0.000ms): __schedule (down_write) 04000001 0.560ms (+0.000ms): sched_clock (__schedule) 04000000 0.561ms (+0.000ms): schedule (down_write) 04000000 0.561ms (+0.000ms): __schedule (down_write) 04000001 0.561ms (+0.000ms): sched_clock (__schedule) 04000000 0.561ms (+0.000ms): schedule (down_write) 04000000 0.561ms (+0.000ms): __schedule (down_write) 04000001 0.561ms (+0.000ms): sched_clock (__schedule) 04000000 0.561ms (+0.000ms): schedule (down_write) 04000000 0.562ms (+0.000ms): __schedule (down_write) 04000001 0.562ms (+0.000ms): sched_clock (__schedule) 04000000 0.562ms (+0.000ms): schedule (down_write) 04000000 0.562ms (+0.000ms): __schedule (down_write) 04000001 0.562ms (+0.000ms): sched_clock (__schedule) 04000000 0.562ms (+0.000ms): schedule (down_write) 04000000 0.562ms (+0.000ms): __schedule (down_write) 04000001 0.563ms (+0.000ms): sched_clock (__schedule) 04000000 0.563ms (+0.000ms): schedule (down_write) 04000000 0.563ms (+0.000ms): __schedule (down_write) 04000001 0.563ms (+0.000ms): sched_clock (__schedule) 04000000 0.563ms (+0.000ms): schedule (down_write) 04000000 0.563ms (+0.000ms): __schedule (down_write) 04000001 0.563ms (+0.000ms): sched_clock (__schedule) 04000000 0.564ms (+0.000ms): schedule (down_write) 04000000 0.564ms (+0.000ms): __schedule (down_write) 04000001 0.564ms (+0.000ms): sched_clock (__schedule) 04000000 0.564ms (+0.000ms): schedule (down_write) 04000000 0.564ms (+0.000ms): __schedule (down_write) 04000001 0.564ms (+0.000ms): sched_clock (__schedule) 04000000 0.565ms (+0.000ms): schedule (down_write) 04000000 0.565ms (+0.000ms): __schedule (down_write) 04000001 0.565ms (+0.000ms): sched_clock (__schedule) 04000000 0.565ms (+0.000ms): schedule (down_write) 04000000 0.565ms (+0.000ms): __schedule (down_write) 04000001 0.565ms (+0.000ms): sched_clock (__schedule) 04000000 0.566ms (+0.000ms): schedule (down_write) 04000000 0.566ms (+0.000ms): __schedule (down_write) 04000001 0.566ms (+0.000ms): sched_clock (__schedule) 04000000 0.566ms (+0.000ms): schedule (down_write) 04000000 0.566ms (+0.000ms): __schedule (down_write) 04000001 0.566ms (+0.000ms): sched_clock (__schedule) 04000000 0.567ms (+0.000ms): schedule (down_write) 04000000 0.567ms (+0.000ms): __schedule (down_write) 04000001 0.567ms (+0.000ms): sched_clock (__schedule) 04000000 0.567ms (+0.000ms): schedule (down_write) 04000000 0.567ms (+0.000ms): __schedule (down_write) 04000001 0.567ms (+0.000ms): sched_clock (__schedule) 04000000 0.567ms (+0.000ms): schedule (down_write) 04000000 0.568ms (+0.000ms): __schedule (down_write) 04000001 0.568ms (+0.000ms): sched_clock (__schedule) 04000000 0.568ms (+0.000ms): schedule (down_write) 04000000 0.568ms (+0.000ms): __schedule (down_write) 04000001 0.568ms (+0.000ms): sched_clock (__schedule) 04000000 0.568ms (+0.000ms): schedule (down_write) 04000000 0.568ms (+0.000ms): __schedule (down_write) 04000001 0.569ms (+0.000ms): sched_clock (__schedule) 04000000 0.569ms (+0.000ms): schedule (down_write) 04000000 0.569ms (+0.000ms): __schedule (down_write) 04000001 0.569ms (+0.000ms): sched_clock (__schedule) 04000000 0.569ms (+0.000ms): schedule (down_write) 04000000 0.569ms (+0.000ms): __schedule (down_write) 04000001 0.569ms (+0.000ms): sched_clock (__schedule) 04000000 0.570ms (+0.000ms): schedule (down_write) 04000000 0.570ms (+0.000ms): __schedule (down_write) 04000001 0.570ms (+0.000ms): sched_clock (__schedule) 04000000 0.570ms (+0.000ms): schedule (down_write) 04000000 0.570ms (+0.000ms): __schedule (down_write) 04000001 0.570ms (+0.000ms): sched_clock (__schedule) 04000000 0.571ms (+0.000ms): schedule (down_write) 04000000 0.571ms (+0.000ms): __schedule (down_write) 04000001 0.571ms (+0.000ms): sched_clock (__schedule) 04000000 0.571ms (+0.000ms): schedule (down_write) 04000000 0.571ms (+0.000ms): __schedule (down_write) 04000001 0.571ms (+0.000ms): sched_clock (__schedule) 04000000 0.572ms (+0.000ms): schedule (down_write) 04000000 0.572ms (+0.000ms): __schedule (down_write) 04000001 0.572ms (+0.000ms): sched_clock (__schedule) 04000000 0.572ms (+0.000ms): schedule (down_write) 04000000 0.572ms (+0.000ms): __schedule (down_write) 04000001 0.572ms (+0.000ms): sched_clock (__schedule) 04000000 0.572ms (+0.000ms): schedule (down_write) 04000000 0.573ms (+0.000ms): __schedule (down_write) 04000001 0.573ms (+0.000ms): sched_clock (__schedule) 04000000 0.573ms (+0.000ms): schedule (down_write) 04000000 0.573ms (+0.000ms): __schedule (down_write) 04000001 0.573ms (+0.000ms): sched_clock (__schedule) 04000000 0.573ms (+0.000ms): schedule (down_write) 04000000 0.574ms (+0.000ms): __schedule (down_write) 04000001 0.574ms (+0.000ms): sched_clock (__schedule) 04000000 0.574ms (+0.000ms): schedule (down_write) 04000000 0.574ms (+0.000ms): __schedule (down_write) 04000001 0.574ms (+0.000ms): sched_clock (__schedule) 04000000 0.574ms (+0.000ms): schedule (down_write) 04000000 0.574ms (+0.000ms): __schedule (down_write) 04000001 0.575ms (+0.000ms): sched_clock (__schedule) 04000000 0.575ms (+0.000ms): schedule (down_write) 04000000 0.575ms (+0.000ms): __schedule (down_write) 04000001 0.575ms (+0.000ms): sched_clock (__schedule) 04000000 0.575ms (+0.000ms): schedule (down_write) 04000000 0.575ms (+0.000ms): __schedule (down_write) 04000001 0.575ms (+0.000ms): sched_clock (__schedule) 04000000 0.576ms (+0.000ms): schedule (down_write) 04000000 0.576ms (+0.000ms): __schedule (down_write) 04000001 0.576ms (+0.000ms): sched_clock (__schedule) 04000000 0.576ms (+0.000ms): schedule (down_write) 04000000 0.576ms (+0.000ms): __schedule (down_write) 04000001 0.576ms (+0.000ms): sched_clock (__schedule) 04000000 0.577ms (+0.000ms): schedule (down_write) 04000000 0.577ms (+0.000ms): __schedule (down_write) 04000001 0.577ms (+0.000ms): sched_clock (__schedule) 04000000 0.577ms (+0.000ms): schedule (down_write) 04000000 0.577ms (+0.000ms): __schedule (down_write) 04000001 0.577ms (+0.000ms): sched_clock (__schedule) 04000000 0.578ms (+0.000ms): schedule (down_write) 04000000 0.578ms (+0.000ms): __schedule (down_write) 04000001 0.578ms (+0.000ms): sched_clock (__schedule) 04000000 0.578ms (+0.000ms): schedule (down_write) 04000000 0.578ms (+0.000ms): __schedule (down_write) 04000001 0.578ms (+0.000ms): sched_clock (__schedule) 04000000 0.578ms (+0.000ms): schedule (down_write) 04000000 0.579ms (+0.000ms): __schedule (down_write) 04000001 0.579ms (+0.000ms): sched_clock (__schedule) 04000000 0.579ms (+0.000ms): schedule (down_write) 04000000 0.579ms (+0.000ms): __schedule (down_write) 04000001 0.579ms (+0.000ms): sched_clock (__schedule) 04000000 0.579ms (+0.000ms): schedule (down_write) 04000000 0.579ms (+0.000ms): __schedule (down_write) 04000001 0.580ms (+0.000ms): sched_clock (__schedule) 04000000 0.580ms (+0.000ms): schedule (down_write) 04000000 0.580ms (+0.000ms): __schedule (down_write) 04000001 0.580ms (+0.000ms): sched_clock (__schedule) 04000000 0.580ms (+0.000ms): schedule (down_write) 04000000 0.580ms (+0.000ms): __schedule (down_write) 04000001 0.581ms (+0.000ms): sched_clock (__schedule) 04000000 0.581ms (+0.000ms): schedule (down_write) 04000000 0.581ms (+0.000ms): __schedule (down_write) 04000001 0.581ms (+0.000ms): sched_clock (__schedule) 04000000 0.581ms (+0.000ms): schedule (down_write) 04000000 0.581ms (+0.000ms): __schedule (down_write) 04000001 0.581ms (+0.000ms): sched_clock (__schedule) 04000000 0.582ms (+0.000ms): schedule (down_write) 04000000 0.582ms (+0.000ms): __schedule (down_write) 04000001 0.582ms (+0.000ms): sched_clock (__schedule) 04000000 0.582ms (+0.000ms): schedule (down_write) 04000000 0.582ms (+0.000ms): __schedule (down_write) 04000001 0.582ms (+0.000ms): sched_clock (__schedule) 04000000 0.583ms (+0.000ms): schedule (down_write) 04000000 0.583ms (+0.000ms): __schedule (down_write) 04000001 0.583ms (+0.000ms): sched_clock (__schedule) 04000000 0.583ms (+0.000ms): schedule (down_write) 04000000 0.583ms (+0.000ms): __schedule (down_write) 04000001 0.583ms (+0.000ms): sched_clock (__schedule) 04000000 0.584ms (+0.000ms): schedule (down_write) 04000000 0.584ms (+0.000ms): __schedule (down_write) 04000001 0.584ms (+0.000ms): sched_clock (__schedule) 04000000 0.584ms (+0.000ms): schedule (down_write) 04000000 0.584ms (+0.000ms): __schedule (down_write) 04000001 0.584ms (+0.000ms): sched_clock (__schedule) 04000000 0.584ms (+0.000ms): schedule (down_write) 04000000 0.585ms (+0.000ms): __schedule (down_write) 04000001 0.585ms (+0.000ms): sched_clock (__schedule) 04000000 0.585ms (+0.000ms): schedule (down_write) 04000000 0.585ms (+0.000ms): __schedule (down_write) 04000001 0.585ms (+0.000ms): sched_clock (__schedule) 04000000 0.585ms (+0.000ms): schedule (down_write) 04000000 0.585ms (+0.000ms): __schedule (down_write) 04000001 0.586ms (+0.000ms): sched_clock (__schedule) 04000000 0.586ms (+0.000ms): schedule (down_write) 04000000 0.586ms (+0.000ms): __schedule (down_write) 04000001 0.586ms (+0.000ms): sched_clock (__schedule) 04000000 0.586ms (+0.000ms): schedule (down_write) 04000000 0.586ms (+0.000ms): __schedule (down_write) 04000001 0.586ms (+0.000ms): sched_clock (__schedule) 04000000 0.587ms (+0.000ms): schedule (down_write) 04000000 0.587ms (+0.000ms): __schedule (down_write) 04000001 0.587ms (+0.000ms): sched_clock (__schedule) 04000000 0.587ms (+0.000ms): schedule (down_write) 04000000 0.587ms (+0.000ms): __schedule (down_write) 04000001 0.587ms (+0.000ms): sched_clock (__schedule) 04000000 0.588ms (+0.000ms): schedule (down_write) 04000000 0.588ms (+0.000ms): __schedule (down_write) 04000001 0.588ms (+0.000ms): sched_clock (__schedule) 04000000 0.588ms (+0.000ms): schedule (down_write) 04000000 0.588ms (+0.000ms): __schedule (down_write) 04000001 0.588ms (+0.000ms): sched_clock (__schedule) 04000000 0.589ms (+0.000ms): schedule (down_write) 04000000 0.589ms (+0.000ms): __schedule (down_write) 04000001 0.589ms (+0.000ms): sched_clock (__schedule) 04000000 0.589ms (+0.000ms): schedule (down_write) 04000000 0.589ms (+0.000ms): __schedule (down_write) 04000001 0.589ms (+0.000ms): sched_clock (__schedule) 04000000 0.590ms (+0.000ms): schedule (down_write) 04000000 0.590ms (+0.000ms): __schedule (down_write) 04000001 0.590ms (+0.000ms): sched_clock (__schedule) 04000000 0.590ms (+0.000ms): schedule (down_write) 04000000 0.590ms (+0.000ms): __schedule (down_write) 04000001 0.590ms (+0.000ms): sched_clock (__schedule) 04000000 0.590ms (+0.000ms): schedule (down_write) 04000000 0.591ms (+0.000ms): __schedule (down_write) 04000001 0.591ms (+0.000ms): sched_clock (__schedule) 04000000 0.591ms (+0.000ms): schedule (down_write) 04000000 0.591ms (+0.000ms): __schedule (down_write) 04000001 0.591ms (+0.000ms): sched_clock (__schedule) 04000000 0.591ms (+0.000ms): schedule (down_write) 04000000 0.591ms (+0.000ms): __schedule (down_write) 04000001 0.592ms (+0.000ms): sched_clock (__schedule) 04000000 0.592ms (+0.000ms): schedule (down_write) 04000000 0.592ms (+0.000ms): __schedule (down_write) 04000001 0.592ms (+0.000ms): sched_clock (__schedule) 04000000 0.592ms (+0.000ms): schedule (down_write) 04000000 0.592ms (+0.000ms): __schedule (down_write) 04000001 0.592ms (+0.000ms): sched_clock (__schedule) 04000000 0.593ms (+0.000ms): schedule (down_write) 04000000 0.593ms (+0.000ms): __schedule (down_write) 04000001 0.593ms (+0.000ms): sched_clock (__schedule) 04000000 0.593ms (+0.000ms): schedule (down_write) 04000000 0.593ms (+0.000ms): __schedule (down_write) 04000001 0.593ms (+0.000ms): sched_clock (__schedule) 04000000 0.594ms (+0.000ms): schedule (down_write) 04000000 0.594ms (+0.000ms): __schedule (down_write) 04000001 0.594ms (+0.000ms): sched_clock (__schedule) 04000000 0.594ms (+0.000ms): schedule (down_write) 04000000 0.594ms (+0.000ms): __schedule (down_write) 04000001 0.594ms (+0.000ms): sched_clock (__schedule) 04000000 0.595ms (+0.000ms): schedule (down_write) 04000000 0.595ms (+0.000ms): __schedule (down_write) 04000001 0.595ms (+0.000ms): sched_clock (__schedule) 04000000 0.595ms (+0.000ms): schedule (down_write) 04000000 0.595ms (+0.000ms): __schedule (down_write) 04000001 0.595ms (+0.000ms): sched_clock (__schedule) 04000000 0.596ms (+0.000ms): schedule (down_write) 04000000 0.596ms (+0.000ms): __schedule (down_write) 04000001 0.596ms (+0.000ms): sched_clock (__schedule) 04000000 0.596ms (+0.000ms): schedule (down_write) 04000000 0.596ms (+0.000ms): __schedule (down_write) 04000001 0.596ms (+0.000ms): sched_clock (__schedule) 04000000 0.596ms (+0.000ms): schedule (down_write) 04000000 0.597ms (+0.000ms): __schedule (down_write) 04000001 0.597ms (+0.000ms): sched_clock (__schedule) 04000000 0.597ms (+0.000ms): schedule (down_write) 04000000 0.597ms (+0.000ms): __schedule (down_write) 04000001 0.597ms (+0.000ms): sched_clock (__schedule) 04000000 0.597ms (+0.000ms): schedule (down_write) 04000000 0.597ms (+0.000ms): __schedule (down_write) 04000001 0.598ms (+0.000ms): sched_clock (__schedule) 04000000 0.598ms (+0.000ms): schedule (down_write) 04000000 0.598ms (+0.000ms): __schedule (down_write) 04000001 0.598ms (+0.000ms): sched_clock (__schedule) 04000000 0.598ms (+0.000ms): schedule (down_write) 04000000 0.598ms (+0.000ms): __schedule (down_write) 04000001 0.598ms (+0.000ms): sched_clock (__schedule) 04000000 0.599ms (+0.000ms): schedule (down_write) 04000000 0.599ms (+0.000ms): __schedule (down_write) 04000001 0.599ms (+0.000ms): sched_clock (__schedule) 04000000 0.599ms (+0.000ms): schedule (down_write) 04000000 0.599ms (+0.000ms): __schedule (down_write) 04000001 0.599ms (+0.000ms): sched_clock (__schedule) 04000000 0.600ms (+0.000ms): schedule (down_write) 04000000 0.600ms (+0.000ms): __schedule (down_write) 04000001 0.600ms (+0.000ms): sched_clock (__schedule) 04000000 0.600ms (+0.000ms): schedule (down_write) 04000000 0.600ms (+0.000ms): __schedule (down_write) 04000001 0.600ms (+0.000ms): sched_clock (__schedule) 04000000 0.601ms (+0.000ms): schedule (down_write) 04000000 0.601ms (+0.000ms): __schedule (down_write) 04000001 0.601ms (+0.000ms): sched_clock (__schedule) 04000000 0.601ms (+0.000ms): schedule (down_write) 04000000 0.601ms (+0.000ms): __schedule (down_write) 04000001 0.601ms (+0.000ms): sched_clock (__schedule) 04000000 0.601ms (+0.000ms): schedule (down_write) 04000000 0.602ms (+0.000ms): __schedule (down_write) 04000001 0.602ms (+0.000ms): sched_clock (__schedule) 04000000 0.602ms (+0.000ms): schedule (down_write) 04000000 0.602ms (+0.000ms): __schedule (down_write) 04000001 0.602ms (+0.000ms): sched_clock (__schedule) 04000000 0.602ms (+0.000ms): schedule (down_write) 04000000 0.602ms (+0.000ms): __schedule (down_write) 04000001 0.603ms (+0.000ms): sched_clock (__schedule) 04000000 0.603ms (+0.000ms): schedule (down_write) 04000000 0.603ms (+0.000ms): __schedule (down_write) 04000001 0.603ms (+0.000ms): sched_clock (__schedule) 04000000 0.603ms (+0.000ms): schedule (down_write) 04000000 0.603ms (+0.000ms): __schedule (down_write) 04000001 0.604ms (+0.000ms): sched_clock (__schedule) 04000000 0.604ms (+0.000ms): schedule (down_write) 04000000 0.604ms (+0.000ms): __schedule (down_write) 04000001 0.604ms (+0.000ms): sched_clock (__schedule) 04000000 0.604ms (+0.000ms): schedule (down_write) 04000000 0.604ms (+0.000ms): __schedule (down_write) 04000001 0.604ms (+0.000ms): sched_clock (__schedule) 04000000 0.605ms (+0.000ms): schedule (down_write) 04000000 0.605ms (+0.000ms): __schedule (down_write) 04000001 0.605ms (+0.000ms): sched_clock (__schedule) 04000000 0.605ms (+0.000ms): schedule (down_write) 04000000 0.605ms (+0.000ms): __schedule (down_write) 04000001 0.605ms (+0.000ms): sched_clock (__schedule) 04000000 0.606ms (+0.000ms): schedule (down_write) 04000000 0.606ms (+0.000ms): __schedule (down_write) 04000001 0.606ms (+0.000ms): sched_clock (__schedule) 04000000 0.606ms (+0.000ms): schedule (down_write) 04000000 0.606ms (+0.000ms): __schedule (down_write) 04000001 0.606ms (+0.000ms): sched_clock (__schedule) 04000000 0.607ms (+0.000ms): schedule (down_write) 04000000 0.607ms (+0.000ms): __schedule (down_write) 04000001 0.607ms (+0.000ms): sched_clock (__schedule) 04000000 0.607ms (+0.000ms): schedule (down_write) 04000000 0.607ms (+0.000ms): __schedule (down_write) 04000001 0.607ms (+0.000ms): sched_clock (__schedule) 04000000 0.607ms (+0.000ms): schedule (down_write) 04000000 0.608ms (+0.000ms): __schedule (down_write) 04000001 0.608ms (+0.000ms): sched_clock (__schedule) 04000000 0.608ms (+0.000ms): schedule (down_write) 04000000 0.608ms (+0.000ms): __schedule (down_write) 04000001 0.608ms (+0.000ms): sched_clock (__schedule) 04000000 0.608ms (+0.000ms): schedule (down_write) 04000000 0.608ms (+0.000ms): __schedule (down_write) 04000001 0.609ms (+0.000ms): sched_clock (__schedule) 04000000 0.609ms (+0.000ms): schedule (down_write) 04000000 0.609ms (+0.000ms): __schedule (down_write) 04000001 0.609ms (+0.000ms): sched_clock (__schedule) 04000000 0.609ms (+0.000ms): schedule (down_write) 04000000 0.609ms (+0.000ms): __schedule (down_write) 04000001 0.610ms (+0.000ms): sched_clock (__schedule) 04000000 0.610ms (+0.000ms): schedule (down_write) 04000000 0.610ms (+0.000ms): __schedule (down_write) 04000001 0.610ms (+0.000ms): sched_clock (__schedule) 04000000 0.610ms (+0.000ms): schedule (down_write) 04000000 0.610ms (+0.000ms): __schedule (down_write) 04000001 0.610ms (+0.000ms): sched_clock (__schedule) 04000000 0.611ms (+0.000ms): schedule (down_write) 04000000 0.611ms (+0.000ms): __schedule (down_write) 04000001 0.611ms (+0.000ms): sched_clock (__schedule) 04000000 0.611ms (+0.000ms): schedule (down_write) 04000000 0.611ms (+0.000ms): __schedule (down_write) 04000001 0.611ms (+0.000ms): sched_clock (__schedule) 04000000 0.612ms (+0.000ms): schedule (down_write) 04000000 0.612ms (+0.000ms): __schedule (down_write) 04000001 0.612ms (+0.000ms): sched_clock (__schedule) 04000000 0.612ms (+0.000ms): schedule (down_write) 04000000 0.612ms (+0.000ms): __schedule (down_write) 04000001 0.612ms (+0.000ms): sched_clock (__schedule) 04000000 0.613ms (+0.000ms): schedule (down_write) 04000000 0.613ms (+0.000ms): __schedule (down_write) 04000001 0.613ms (+0.000ms): sched_clock (__schedule) 04000000 0.613ms (+0.000ms): schedule (down_write) 04000000 0.613ms (+0.000ms): __schedule (down_write) 04000001 0.613ms (+0.000ms): sched_clock (__schedule) 04000000 0.613ms (+1168210.574ms): schedule (down_write)

mango:~# uname -a
Linux mango.fruits.de 2.6.9-rc4-mm1-RT-U6 #1 Tue Oct 19 17:59:48 CEST 2004 i686 GNU/Linux
mango:~# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1195.144
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 2359.29

#
# Automatically generated make config: don't edit # Linux kernel version: 2.6.9-rc4-mm1-RT-U6
# Tue Oct 19 17:39:11 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support #
# CONFIG_ACPI is not set CONFIG_ACPI_BLACKLIST_YEAR=0

#
# APM (Advanced Power Management) BIOS Support #
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

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

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

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

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

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

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set CONFIG_SCSI_QLA2XXX=m
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE 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_TUNNEL is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE 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_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

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

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

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

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

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

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set

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

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

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
# CONFIG_I2C is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=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_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
CONFIG_AFS_FS=m
CONFIG_RXRPC=m

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

#
# Native Language Support
#
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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# 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 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RWSEM_DEADLOCK_DETECT=y
CONFIG_RWSEM_MAX_OWNERS=64
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

#199 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 10 lines · Florian Schmidt

I don't get any oopses or panics, but i can observer a rather interesting behaviour. When i enable the latency traces via

echo 1 > /proc/sys/kernel/trace_enabled

my machine starts to make little pauses of ca 3-4 secs. X "hangs" for this duration and so does aplay when playing a .wav file. "hangs" means that the X display seems to be locked. Interestingly enough all keystrokes i entered during the "hang" seem to arrive fine after the hang has ended. aplay experiences an xrun.

do you get the same pauses if you do 'dmesg -n 1'? Also, are you using preempt_thresh or the maximum-searching variant? preempt_thresh can generate _tons_ of messages with a low threshold, freezing the system in essence for long periods of time.

but this trace is weird:

Quoted 6 lines

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
latency: 1841 us, entries: 4000 (12990) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]

    -----------------
    | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------
Quoted 16 lines

=> started at: __schedule+0x3b/0x5d0 <c02a767b>
=> ended at: finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
00000001 0.000ms (+0.000ms): __schedule (ksoftirqd) 00000001 0.000ms (+0.000ms): sched_clock (__schedule) 00000002 0.000ms (+0.000ms): deactivate_task (__schedule) 00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task) 04000002 0.000ms (+0.000ms): __switch_to (__schedule) 04000002 0.001ms (+0.000ms): finish_task_switch (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.001ms (+0.000ms): sched_clock (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.002ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write)

this doesnt seem like normal behavior. It seems two tasks are ping-pong-ing a semaphore but are unable to make any progress. The whole thing is non-preemptible because this semaphore was taken while in a PREEMPT_ACTIVE section.

(i'd say this is the BKL semaphore - it is quite special in that regard.)

Ingo

#200 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 4 lines · On Tue, 19 Oct 2004 18:56:46 +0200 Ingo Molnar <[email protected]> wrote:

do you get the same pauses if you do 'dmesg -n 1'? Also, are you using preempt_thresh or the maximum-searching variant? preempt_thresh can generate _tons_ of messages with a low threshold, freezing the system in essence for long periods of time.

afaik i use the maximum search:

mango:~# cat /proc/sys/kernel/preempt_thresh 
0
mango:~# cat /proc/sys/kernel/preempt_max_latency 
1841

I'll compile a kernel w/o preempt-timing and tracing. But i will get to it tomorrow the earliest.

Quoted 1 line

but this trace is weird:

[snip]

Quoted 7 lines

this doesnt seem like normal behavior. It seems two tasks are ping-pong-ing a semaphore but are unable to make any progress. The whole thing is non-preemptible because this semaphore was taken while in a PREEMPT_ACTIVE section.

(i'd say this is the BKL semaphore - it is quite special in that regard.)

btw: afaics these long critical sections reports do not correlate to the pauses X makes (not sure though). I have anther long one. This is from syslog as i haven't had the tracing enabled at that time:

(IRQ 3/117/CPU#0): new 1385 us maximum-latency critical section.
=> started at timestamp 2293619762: <call_console_drivers+0x76/0x140>
=> ended at timestamp 2293621147: <finish_task_switch+0x43/0xb0>

 [<c012f630>] sub_preempt_count+0x60/0x90
 [<c012f31e>] check_preempt_timing+0x15e/0x270
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c012f630>] sub_preempt_count+0x60/0x90
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c02a7917>] __schedule+0x2d7/0x5d0
 [<c0136faa>] do_irqd+0x5a/0x80
 [<c0112440>] mcount+0x14/0x18
 [<c0136faa>] do_irqd+0x5a/0x80
 [<c012d82a>] kthread+0xaa/0xb0
 [<c0136f50>] do_irqd+0x0/0x80
 [<c012d780>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x3b/0x5d0 / (do_irqd+0x5a/0x80) .. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

=> dump-end timestamp 2293621634

Here's a similar (to the one from my last mail) shorter one:

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
latency: 471 us, entries: 2562 (2562) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]

    -----------------
    | task: xterm/3155, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------

=> started at: cond_resched+0x23/0x80 <c02a82b3>
=> ended at: finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
04000001 0.000ms (+0.000ms): __rwsem_deadlock (down_write) 04000000 0.000ms (+0.000ms): schedule (down_write) 04000000 0.000ms (+0.000ms): __schedule (down_write) 04000001 0.000ms (+0.000ms): sched_clock (__schedule) 04000000 0.000ms (+0.000ms): schedule (down_write) 04000000 0.000ms (+0.000ms): __schedule (down_write) 04000001 0.000ms (+0.000ms): sched_clock (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.001ms (+0.000ms): sched_clock (__schedule) 04000000 0.001ms (+0.000ms): schedule (down_write) 04000000 0.001ms (+0.000ms): __schedule (down_write) 04000001 0.001ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write) 04000000 0.002ms (+0.000ms): __schedule (down_write) 04000001 0.002ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write) 04000000 0.002ms (+0.000ms): __schedule (down_write) 04000001 0.002ms (+0.000ms): sched_clock (__schedule) 04000000 0.002ms (+0.000ms): schedule (down_write) 04000000 0.002ms (+0.000ms): __schedule (down_write) 04000001 0.003ms (+0.000ms): sched_clock (__schedule) 04000000 0.003ms (+0.000ms): schedule (down_write) 04000000 0.003ms (+0.000ms): __schedule (down_write) 04000001 0.003ms (+0.000ms): sched_clock (__schedule) 04000000 0.003ms (+0.000ms): schedule (down_write)

[many many more]

04000000 0.445ms (+0.000ms): __schedule (down_write)
04000001 0.445ms (+0.000ms): sched_clock (__schedule) 04000000 0.446ms (+0.000ms): schedule (down_write)
04000000 0.446ms (+0.000ms): __schedule (down_write)
04000001 0.446ms (+0.000ms): sched_clock (__schedule) 04000000 0.446ms (+0.000ms): schedule (down_write)
04000000 0.446ms (+0.000ms): __schedule (down_write)
04000001 0.447ms (+0.000ms): sched_clock (__schedule) 04000000 0.447ms (+0.000ms): schedule (down_write)
04000000 0.447ms (+0.000ms): __schedule (down_write)
04000001 0.447ms (+0.000ms): sched_clock (__schedule) 04000000 0.447ms (+0.000ms): schedule (down_write)
04000000 0.447ms (+0.000ms): __schedule (down_write)
04000001 0.448ms (+0.000ms): sched_clock (__schedule) 04000000 0.448ms (+0.000ms): schedule (down_write)
04000000 0.448ms (+0.000ms): __schedule (down_write)
04000001 0.448ms (+0.000ms): sched_clock (__schedule) 04000000 0.448ms (+0.000ms): schedule (down_write)
04000000 0.449ms (+0.000ms): __schedule (down_write)
04000001 0.449ms (+0.000ms): sched_clock (__schedule) 04000000 0.449ms (+0.000ms): schedule (down_write)
04000000 0.449ms (+0.000ms): __schedule (down_write)
04000001 0.449ms (+0.000ms): sched_clock (__schedule) 04000000 0.449ms (+0.000ms): schedule (down_write)
04000000 0.450ms (+0.000ms): __schedule (down_write)
04000001 0.450ms (+0.000ms): sched_clock (__schedule) 04000000 0.450ms (+0.000ms): schedule (down_write)
04000000 0.450ms (+0.000ms): __schedule (down_write)
04000001 0.450ms (+0.000ms): sched_clock (__schedule) 04000000 0.450ms (+0.000ms): schedule (down_write)
04000000 0.451ms (+0.000ms): __schedule (down_write)
04000001 0.451ms (+0.000ms): sched_clock (__schedule) 04000000 0.451ms (+0.000ms): schedule (down_write)
04000000 0.451ms (+0.000ms): __schedule (down_write)
04000001 0.451ms (+0.000ms): sched_clock (__schedule) 04000000 0.452ms (+0.000ms): schedule (down_write)
04000000 0.452ms (+0.000ms): __schedule (down_write)
04000001 0.452ms (+0.000ms): sched_clock (__schedule) 04000000 0.452ms (+0.000ms): schedule (down_write)
04000000 0.452ms (+0.000ms): __schedule (down_write)
04000001 0.452ms (+0.000ms): sched_clock (__schedule) 04000000 0.453ms (+0.000ms): schedule (down_write)
04000000 0.453ms (+0.000ms): __schedule (down_write)
04000001 0.453ms (+0.000ms): sched_clock (__schedule) 04000000 0.453ms (+0.000ms): schedule (down_write)
04000000 0.453ms (+0.000ms): __schedule (down_write)
04000001 0.453ms (+0.000ms): sched_clock (__schedule) 04000000 0.454ms (+0.000ms): schedule (down_write)
04000000 0.454ms (+0.000ms): __schedule (down_write)
04000001 0.454ms (+0.000ms): sched_clock (__schedule) 04000000 0.454ms (+0.000ms): schedule (down_write)
04000000 0.454ms (+0.001ms): __schedule (down_write)
04010000 0.455ms (+0.000ms): do_IRQ (add_preempt_count) 04010000 0.455ms (+0.000ms): do_IRQ (<00000000>)
00010001 0.456ms (+0.001ms): mask_and_ack_8259A (__do_IRQ) 00010001 0.458ms (+0.000ms): redirect_hardirq (__do_IRQ) 00010000 0.458ms (+0.000ms): handle_IRQ_event (__do_IRQ) 00010000 0.458ms (+0.000ms): timer_interrupt (handle_IRQ_event) 00010001 0.458ms (+0.006ms): mark_offset_tsc (timer_interrupt) 00010001 0.464ms (+0.000ms): do_timer (timer_interrupt) 00010001 0.465ms (+0.000ms): update_wall_time (do_timer) 00010001 0.465ms (+0.000ms): update_wall_time_one_tick (update_wall_time) 00010001 0.465ms (+0.000ms): update_process_times (timer_interrupt) 00010001 0.465ms (+0.000ms): update_one_process (update_process_times) 00010001 0.465ms (+0.000ms): run_local_timers (update_process_times) 00010001 0.466ms (+0.000ms): raise_softirq (update_process_times) 00010001 0.466ms (+0.000ms): scheduler_tick (update_process_times) 00010001 0.466ms (+0.000ms): sched_clock (scheduler_tick) 00010002 0.466ms (+0.000ms): task_timeslice (scheduler_tick) 00010002 0.467ms (+0.000ms): dequeue_task (scheduler_tick) 00010002 0.467ms (+0.000ms): effective_prio (scheduler_tick) 00010002 0.467ms (+0.000ms): enqueue_task (scheduler_tick) 00010001 0.468ms (+0.000ms): note_interrupt (__do_IRQ) 00010001 0.468ms (+0.000ms): end_8259A_irq (__do_IRQ) 00010001 0.468ms (+0.000ms): enable_8259A_irq (__do_IRQ) 04010000 0.469ms (+0.000ms): irq_exit (do_IRQ)
04000001 0.469ms (+0.000ms): sched_clock (__schedule) 00000002 0.470ms (+0.000ms): __switch_to (__schedule) 00000002 0.470ms (+0.000ms): finish_task_switch (__schedule)

one more:

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
latency: 2363 us, entries: 4000 (15429) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1]

    -----------------
    | task: xterm/3155, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------

=> started at: cond_resched+0x23/0x80 <c02a82b3>
=> ended at: finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
04000001 0.000ms (+0.000ms): __rwsem_deadlock (down_write) 04000000 0.000ms (+0.000ms): schedule (down_write) 04000000 0.000ms (+0.000ms): __schedule (down_write) 04000001 0.000ms (+0.000ms): sched_clock (__schedule) 04000000 0.000ms (+0.000ms): schedule (down_write) 04000000 0.000ms (+0.000ms): __schedule (down_write)

[more]

04000000 0.347ms (+0.000ms): schedule (down_write)
04000000 0.348ms (+0.000ms): __schedule (down_write)
04000001 0.348ms (+0.000ms): sched_clock (__schedule) 04000000 0.348ms (+0.000ms): schedule (down_write)
04000000 0.348ms (+0.000ms): __schedule (down_write)
04000001 0.348ms (+0.000ms): sched_clock (__schedule) 04000000 0.349ms (+0.000ms): schedule (down_write)
04000000 0.349ms (+0.000ms): __schedule (down_write)
04000001 0.349ms (+0.000ms): sched_clock (__schedule) 04000000 0.349ms (+0.000ms): schedule (down_write)
04000000 0.349ms (+0.000ms): __schedule (down_write)
04000001 0.349ms (+0.000ms): sched_clock (__schedule) 04000000 0.350ms (+0.000ms): schedule (down_write)
04000000 0.350ms (+0.000ms): __schedule (down_write)
04000001 0.350ms (+0.000ms): sched_clock (__schedule) 04000000 0.350ms (+0.000ms): schedule (down_write)
04000000 0.350ms (+0.000ms): __schedule (down_write)
04000001 0.351ms (+0.000ms): sched_clock (__schedule) 04000000 0.351ms (+0.000ms): schedule (down_write)
04000000 0.351ms (+0.000ms): __schedule (down_write)
04000001 0.351ms (+0.000ms): sched_clock (__schedule) 04000000 0.352ms (+0.000ms): schedule (down_write)
04000000 0.352ms (+0.000ms): __schedule (down_write)
04010001 0.352ms (+0.000ms): do_IRQ (add_preempt_count) 04010001 0.353ms (+0.000ms): do_IRQ (<00000000>)
00010001 0.353ms (+0.001ms): mask_and_ack_8259A (__do_IRQ) 00010001 0.355ms (+0.000ms): redirect_hardirq (__do_IRQ) 00010000 0.355ms (+0.000ms): handle_IRQ_event (__do_IRQ) 00010000 0.355ms (+0.000ms): timer_interrupt (handle_IRQ_event) 00010001 0.356ms (+0.006ms): mark_offset_tsc (timer_interrupt) 00010001 0.362ms (+0.000ms): do_timer (timer_interrupt) 00010001 0.363ms (+0.000ms): update_wall_time (do_timer) 00010001 0.363ms (+0.000ms): update_wall_time_one_tick (update_wall_time) 00010001 0.363ms (+0.000ms): update_process_times (timer_interrupt) 00010001 0.363ms (+0.000ms): update_one_process (update_process_times) 00010001 0.363ms (+0.000ms): run_local_timers (update_process_times) 00010001 0.363ms (+0.000ms): raise_softirq (update_process_times) 00010001 0.364ms (+0.000ms): scheduler_tick (update_process_times) 00010001 0.364ms (+0.000ms): sched_clock (scheduler_tick) 00010002 0.364ms (+0.000ms): task_timeslice (scheduler_tick) 00010001 0.365ms (+0.000ms): note_interrupt (__do_IRQ) 00010001 0.365ms (+0.000ms): end_8259A_irq (__do_IRQ) 00010001 0.365ms (+0.000ms): enable_8259A_irq (__do_IRQ) 04010001 0.366ms (+0.000ms): irq_exit (do_IRQ)
04000001 0.367ms (+0.000ms): sched_clock (__schedule) 04000000 0.367ms (+0.000ms): schedule (down_write)
04000000 0.367ms (+0.000ms): __schedule (down_write)
04000001 0.367ms (+0.000ms): sched_clock (__schedule) 04000000 0.368ms (+0.000ms): schedule (down_write)
04000000 0.368ms (+0.000ms): __schedule (down_write)
04000001 0.368ms (+0.000ms): sched_clock (__schedule) 04000000 0.368ms (+0.000ms): schedule (down_write)
04000000 0.368ms (+0.000ms): __schedule (down_write)
04000001 0.369ms (+0.000ms): sched_clock (__schedule) 04000000 0.369ms (+0.000ms): schedule (down_write)
04000000 0.369ms (+0.000ms): __schedule (down_write)
04000001 0.369ms (+0.000ms): sched_clock (__schedule) 04000000 0.370ms (+0.000ms): schedule (down_write)
04000000 0.370ms (+0.000ms): __schedule (down_write)
04000001 0.370ms (+0.000ms): sched_clock (__schedule) 04000000 0.370ms (+0.000ms): schedule (down_write)

[more]

04000000 0.797ms (+0.000ms): schedule (down_write) 04000000 0.797ms (+0.000ms): __schedule (down_write) 04000001 0.797ms (+0.000ms): sched_clock (__schedule) 04000000 0.797ms (+0.000ms): schedule (down_write) 04000000 0.798ms (+0.000ms): __schedule (down_write) 04000001 0.798ms (+0.000ms): sched_clock (__schedule) 04000000 0.798ms (+0.000ms): schedule (down_write) 04000000 0.798ms (+0.000ms): __schedule (down_write) 04000001 0.798ms (+0.000ms): sched_clock (__schedule) 04000000 0.799ms (+0.000ms): schedule (down_write) 04000000 0.799ms (+0.000ms): __schedule (down_write) 04000001 0.799ms (+0.000ms): sched_clock (__schedule) 04000000 0.799ms (+0.000ms): schedule (down_write) 04000000 0.799ms (+0.000ms): __schedule (down_write) 04000001 0.800ms (+0.000ms): sched_clock (__schedule) 04000000 0.800ms (+0.000ms): schedule (down_write) 04000000 0.800ms (+0.000ms): __schedule (down_write) 04000001 0.800ms (+877840.005ms): sched_clock (__schedule)

fio

#201 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Ingo Molnar
Quoted 3 lines · Ingo Molnar

* Ingo Molnar <[email protected]> wrote:
i've re-released the patch because shortly after releasing it i found a false-positive in the deadlock-detector that was triggering in oowriter.

Hit and converted another one. There are more, but they need more modifications as they don't have a condition to wait for and therefor must be converted to use the completion API, which must be extended to provide completion_timemout() first.

tglx

net/sunrpc/clnt.c +2 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U6/net/sunrpc/clnt.c 2.6.9-rc4-mm1-VP-U4-LRT1/net/sunrpc/clnt.c
@@ -231,7 +231,8 @@
 		clnt->cl_oneshot = 0;
 		clnt->cl_dead = 0;
 		rpc_killall_tasks(clnt);
-		sleep_on_timeout(&destroy_wait, 1*HZ);
+		wait_event_timeout(destroy_wait, 
+			atomic_read(&clnt->cl_users) > 0, 1*HZ);
 	}
 
 	if (atomic_read(&clnt->cl_users) < 0) {
#202 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 9 lines · Thomas Gleixner
Quoted 3 lines · Ingo Molnar

* Ingo Molnar <[email protected]> wrote:
i've re-released the patch because shortly after releasing it i found a false-positive in the deadlock-detector that was triggering in oowriter.

Hit and converted another one. There are more, but they need more modifications as they don't have a condition to wait for and therefor must be converted to use the completion API, which must be extended to provide completion_timemout() first.

thanks, i've applied your patch to my tree. Find below an untested implementation of wait_for_completion_timeout().

Ingo

kernel/sched.c renamed from kernel/sched.c.orig +25 -0
@@ -3070,6 +3148,31 @@ void fastcall __sched wait_for_completio
 }
 EXPORT_SYMBOL(wait_for_completion);
 
+unsigned long fastcall __sched
+wait_for_completion_timeout(struct completion *x, unsigned long timeout)
+{
+	might_sleep();
+	spin_lock_irq(&x->wait.lock);
+	if (!x->done) {
+		DECLARE_WAITQUEUE(wait, current);
+
+		wait.flags |= WQ_FLAG_EXCLUSIVE;
+		__add_wait_queue_tail(&x->wait, &wait);
+		do {
+			__set_current_state(TASK_UNINTERRUPTIBLE);
+			spin_unlock_irq(&x->wait.lock);
+			timeout = schedule_timeout(timeout);
+			spin_lock_irq(&x->wait.lock);
+		} while (!x->done);
+		__remove_wait_queue(&x->wait, &wait);
+	}
+	x->done--;
+	spin_unlock_irq(&x->wait.lock);
+
+	return timeout;
+}
+EXPORT_SYMBOL(wait_for_completion_timeout);
+
 #define	SLEEP_ON_VAR					\
 	unsigned long flags;				\
 	wait_queue_t wait;				\
include/linux/completion.h renamed from include/linux/completion.h.orig +2 -0
@@ -28,6 +28,8 @@ static inline void init_completion(struc
 }
 
 extern void FASTCALL(wait_for_completion(struct completion *));
+extern unsigned long FASTCALL(wait_for_completion_timeout(struct completion *,
+							  unsigned long));
 extern void FASTCALL(complete(struct completion *));
 extern void FASTCALL(complete_all(struct completion *));
 
#203 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 2 lines · Ingo Molnar

thanks, i've applied your patch to my tree. Find below an untested implementation of wait_for_completion_timeout().

Will give it a try.

Found another exterm ugly one. In scsi_error_handler a mutex is initialized locked and then it is acquired again with down_interruptible()

I have no fix yet. Somebody else ?

tglx

PCI: Found IRQ 10 for device 0000:00:02.0
sym0: <875> rev 0x4 at pci 0000:00:02.0 irq 10

BUG: semaphore recursion deadlock detected!
.. current task scsi_eh_0/730 is already holding cfed3ed8.
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 c025a590 00000000 c0104115 cfed7800 00000000 00000000
Call Trace:
 [<c025a590>] scsi_error_handler+0x0/0x100
 [<c0104115>] kernel_thread_helper+0x5/0x10
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:472!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c0307bb5>]    Not tainted VLI
EFLAGS: 00010046   (2.6.9-rc4-mm1-RT-U6)

EIP is at __down_write_interruptible+0xd5/0x296
eax: 00000001 ebx: 00000000 ecx: c036222c edx: 00000001
esi: cfed3ed8 edi: cfd04070 ebp: 00000001 esp: cfed3e8c
ds: 007b es: 007b ss: 0068 preempt: 00000003
Process scsi_eh_0 (pid: 730, threadinfo=cfed2000 task=cfd04070)

Stack: cfed3ed8 00000000 00000000 cfed3edc cfed3edc cfd04070 00000002
cfed2000
       cfed3ed8 cfed3ed8 00000000 c01c6ae4 cfed3ed8 cfd04070 cfed7800
00000000
       c025a617 c032a106 00000000 ffffffff cfed3e98 cfed3e98 00000001
cfd04070
Call Trace:
 [<c01c6ae4>] down_write_interruptible+0x44/0x70
 [<c025a617>] scsi_error_handler+0x87/0x100
 [<c025a590>] scsi_error_handler+0x0/0x100
 [<c0104115>] kernel_thread_helper+0x5/0x10
Code: 08 89 44 24 10 89 34 24 e8 29 e7 eb ff 89 34 24 e8 d1 e7 eb ff 85

c0 74 1a 8b 2d 20 b6 36 c0 85 ed 74 10 31 db 89 1d 2
<6>note: scsi_eh_0[730] exited with preempt_count 2

#204 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U6 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

Quoted 7 lines

this is a fixes-only release.

found and fixed the 'big bug' that was probably the one causing stability problems for a number of people. There was a small window for a task double-free race to occur, causing all sorts of crashes later on. This bug could trigger on UP and SMP systems alike, on SMP being a bit more frequent.

I am still having the same bug(repeatable by running liquidwar) as I reported with -U5(see my earlier email).

#205 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 2 lines · Adam Heath

I am still having the same bug(repeatable by running liquidwar) as I reported with -U5(see my earlier email).

ok, this seems to be some questionable code in OSS. It really has no business up()-ing the inode semaphore - nobody down()-ed it before! This could be either a bad workaround for a bug/hang someone saw, or an old VFS assumption that doesnt hold anymore. In any case, could you try the patch below, does it fix liquidwar?

Ingo

sound/core/oss/pcm_oss.c renamed from sound/core/oss/pcm_oss.c.orig +0 -2
@@ -2120,9 +2120,7 @@ static ssize_t snd_pcm_oss_write(struct 
 	substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK];
 	if (substream == NULL)
 		return -ENXIO;
-	up(&file->f_dentry->d_inode->i_sem);
 	result = snd_pcm_oss_write1(substream, buf, count);
-	down(&file->f_dentry->d_inode->i_sem);
 #ifdef OSS_DEBUG
 	printk("pcm_oss: write %li bytes (wrote %li bytes)\n", (long)count, (long)result);
 #endif
#206 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 11 lines · Ingo Molnar
Quoted 2 lines · Adam Heath

I am still having the same bug(repeatable by running liquidwar) as I reported with -U5(see my earlier email).

ok, this seems to be some questionable code in OSS. It really has no business up()-ing the inode semaphore - nobody down()-ed it before! This could be either a bad workaround for a bug/hang someone saw, or an old VFS assumption that doesnt hold anymore. In any case, could you try the patch below, does it fix liquidwar?

Yup, the below fixes it. However, this problem *only* started occuring in -U5. I've been running liquidwar on all versions(it's my current game-to-play-when-I-feel-stupid program).

Quoted 21 lines

Ingo

sound/core/oss/pcm_oss.c renamed from sound/core/oss/pcm_oss.c.orig +0 -3
@@ -2120,9 +2120,7 @@ static ssize_t snd_pcm_oss_write(struct
 	substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK];
 	if (substream == NULL)
 		return -ENXIO;
-	up(&file->f_dentry->d_inode->i_sem);
 	result = snd_pcm_oss_write1(substream, buf, count);
-	down(&file->f_dentry->d_inode->i_sem);
 #ifdef OSS_DEBUG
 	printk("pcm_oss: write %li bytes (wrote %li bytes)\n", (long)count, (long)result);
 #endif
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#207 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6

Quoted 14 lines · Adam Heath
Quoted 11 lines · Ingo Molnar
Quoted 2 lines · Adam Heath

I am still having the same bug(repeatable by running liquidwar) as I reported with -U5(see my earlier email).

ok, this seems to be some questionable code in OSS. It really has no business up()-ing the inode semaphore - nobody down()-ed it before! This could be either a bad workaround for a bug/hang someone saw, or an old VFS assumption that doesnt hold anymore. In any case, could you try the patch below, does it fix liquidwar?

Quoted 3 lines

Yup, the below fixes it. However, this problem *only* started occuring in -U5. I've been running liquidwar on all versions(it's my current game-to-play-when-I-feel-stupid program).

The real fix is to use ALSA. :-)

Lee

#208 lore raw

PATCH 1/1 Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

this too is a fixes-only release.

Changes since -U6:

- crash fix: turn off 4K stacks when using RWSEM_DEADLOCK_DETECTION, and tune down the default max # of tasks traced per semaphore. This increases process-stack size and reduces the footprint of lock objects. This should fix the bootup crash reported by Rui Nuno Capela.

- assert fix: fixed an ide-taskfile scheduling-with-irqs-off assert that Rui's .config triggers.

- assert workaround: disabled PARPORT_1284 for now, this should fix the assert seen by Mark H Johnson.

- NFS fix: clnt.c fix from Thomas Gleixner

- debugging helper: print stackframe-size in backtraces.

- large-stackframe fix: inflate.c fix

to create a -U7 tree from scratch, the patching order is:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
+ http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
+ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
+ http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

Ingo

#209 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 1 line · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

Another simple fix.

tglx

sound/core/rawmidi.c +2 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U6a/sound/core/rawmidi.c 2.6.9-rc4-mm1-VP-U4-LRT1/sound/core/rawmidi.c
@@ -134,7 +134,8 @@
 	err = 0;
 	runtime->drain = 1;
 	while (runtime->avail < runtime->buffer_size) {
-		timeout = interruptible_sleep_on_timeout(&runtime->sleep, 10 * HZ);
+		timeout = wait_event_interruptible_timeout(runtime->sleep, 
+				runtime->avail < runtime->buffer_size, 10 * HZ);
 		if (signal_pending(current)) {
 			err = -ERESTARTSYS;
 			break;
#210 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 4 lines · Thomas Gleixner
Quoted 1 line · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

Another simple fix.

Another one using wait_for_completion_timeout(). No problems so far.

tglx

fs/lockd/clntlock.c +7 -5
diff -urN 2.6.9-rc4-mm1-RT-U7/fs/lockd/clntlock.c 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/clntlock.c
@@ -6,6 +6,7 @@
  * Copyright (C) 1996, Olaf Kirch <[email protected]>
  */
 
+#include <linux/completion.h>
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/time.h>
@@ -32,7 +33,7 @@
  */
 struct nlm_wait {
 	struct nlm_wait *	b_next;		/* linked list */
-	wait_queue_head_t	b_wait;		/* where to wait on */
+	struct completion	b_wait;		/* where to wait on */
 	struct nlm_host *	b_host;
 	struct file_lock *	b_lock;		/* local file lock */
 	unsigned short		b_reclaim;	/* got to reclaim lock */
@@ -53,7 +54,7 @@
 
 	block.b_host   = host;
 	block.b_lock   = fl;
-	init_waitqueue_head(&block.b_wait);
+	init_completion(&block.b_wait);
 	block.b_status = NLM_LCK_BLOCKED;
 	block.b_next   = nlm_blocked;
 	nlm_blocked    = &block;
@@ -69,7 +70,8 @@
 	 * a 1 minute timeout would do. See the comment before
 	 * nlmclnt_lock for an explanation.
 	 */
-	sleep_on_timeout(&block.b_wait, 30*HZ);
+	
+	wait_for_completion_timeout(&block.b_wait, 30*HZ);
 
 	for (head = &nlm_blocked; *head; head = &(*head)->b_next) {
 		if (*head == &block) {
@@ -118,7 +120,7 @@
 	 * wake up the caller.
 	 */
 	block->b_status = NLM_LCK_GRANTED;
-	wake_up(&block->b_wait);
+	complete(&block->b_wait);
 
 	return nlm_granted;
 }
@@ -233,7 +235,7 @@
 	for (block = nlm_blocked; block; block = block->b_next) {
 		if (block->b_host == host) {
 			block->b_status = NLM_LCK_DENIED_GRACE_PERIOD;
-			wake_up(&block->b_wait);
+			complete(&block->b_wait);
 		}
 	}
 
#211 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Thomas Gleixner
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

Nobrainer typo removal. I'm feeling stupid.

tglx

fs/lockd/svc.c +1 -1
diff -urN 2.6.9-rc4-mm1-RT-U7/fs/lockd/svc.c 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/svc.c
@@ -306,7 +306,7 @@
 	 * Wait for the lockd process to exit, but since we're holding
 	 * the lockd semaphore, we can't wait around forever ...
 	 */
-	if (!wait_event_interruptible_timeout(lockd_exit, 
+	if (wait_event_interruptible_timeout(lockd_exit, 
 					     nlmsvc_pid == 0, HZ) <= 0) {
 		printk(KERN_WARNING 
 			"lockd_down: lockd failed to exit, clearing pid\n");
#212 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

You should seriously think about using a kind of bitkeeper or CVS stle system so that multipule folks can dump stuff into it rapidly. This project is large enough that it needs some kind of facility like that.

bill

#213 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 9 lines · Bill Huey
Quoted 4 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

You should seriously think about using a kind of bitkeeper or CVS stle system so that multipule folks can dump stuff into it rapidly. This project is large enough that it needs some kind of facility like that.

We also might want to consider a separate mailing list, if the volume of mail gets unwieldy, then just post release announcements to LKML. The volume is high enough and some of the terminology different enough that we already had one inadvertent bout of flaming over some unfortunate miscommunication. As more people get involved this could get out of hand. The cc: lists are getting pretty long, and a lot of the testing requires posting huge traces. Think about how many copies of each mail vger has to deliver...

Anyway, I am fine with continuing on LKML, it would really depend on how Ingo and especially the people for whom this is all noise feel about it.

Lee

#214 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

With U7 I'm now able to boot and go all the way into X/KDE with a SMP+PREEMPT_REALTIME configured kernel (config.gz attached) and reboot into it, again and again. Things are getting better, really, but ...

Overall behavior is still unreliable. Many things stop functioning once and for good (until reboot). The shutdown sequence is also prone to busy hanging.

As an aside, my greatest complaint is that jackd -R doesn't work at all:

JACK: unable to mlock() port buffers: Cannot allocate memory
jack_create_thread: error -1 switching current thread to rt for
inheritance: Unknown error 4294967295
cannot start watchdog thread
cannot load driver module alsa

Another example, and one of the very few that were verbose on dmesg, while accessing the floppy disk (subfs mounted), I got:

kernel BUG at fs/buffer.c:2702!
invalid operand: 0000 [#1]
PREEMPT SMP

Modules linked in: nls_iso8859_15 nls_cp860 vfat fat nls_base snd_seq

usbhid ehc
i_hcd intel_mch_agp agpgart uhci_hcd mga snd_usb_usx2y snd_usb_lib snd_rawmidi s
nd_seq_device snd_hwdep snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundc
ore snd_page_alloc evdev sk98lin w83781d i2c_sensor i2c_isa i2c_i801 i2c_core wa
com usbcore subfs dm_mod

CPU:    0
EIP:    0060:[<c015a9c2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.9-rc4-mm1-RT-U7.0smp)

EIP is at submit_bh+0x119/0x126
eax: 00000004 ebx: f16d683c ecx: 00000000 edx: f12e2000
esi: f16d683c edi: 00000000 ebp: f12e3d90 esp: f12e3d78
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process submountd (pid: 11393, threadinfo=f12e2000 task=f6116950)

Stack: 00000000 00000200 00000000 f16d683c fffffffb f64b0800 f12e3da4
c01587e3
       00000000 f16d683c f4675000 f12e3db8 c0158ab1 f16d683c 00000000
00000200
       f12e3e34 f8c7e85b f673d500 00000000 00000200 f4675148 f12e3de8
c02ca60c
Call Trace:
 [<c0105235>] show_stack+0xaf/0xb7 (28)
 [<c01053c5>] show_registers+0x168/0x1dd (56)
 [<c01055ce>] die+0x107/0x18f (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (92)
 [<c01587e3>] __bread_slow+0x60/0xb2 (20)
 [<c0158ab1>] __bread+0x33/0x39 (20)
 [<f8c7e85b>] fat_fill_super+0xe6/0x76c [fat] (124)
 [<f8c43d70>] vfat_fill_super+0x30/0x67 [vfat] (32)
 [<c015d220>] get_sb_bdev+0xf1/0x147 (72)
 [<f8c43dd5>] vfat_get_sb+0x2e/0x31 [vfat] (28)
 [<c015d492>] do_kern_mount+0xa5/0x15a (44)
 [<c0172f0d>] do_new_mount+0x71/0xab (52)
 [<c01735e3>] do_mount+0x184/0x1ae (116)
 [<c0173a21>] sys_mount+0x97/0xd6 (48)
 [<c01043b9>] sysenter_past_esp+0x52/0x71 (-8124)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x17/0x70 / (die+0x3f/0x18f) .. entry 2: print_traces+0x16/0x4c / (show_stack+0xaf/0xb7)

Code: 24 e8 28 08 00 00 8b 45 f0 83 c4 0c 5b 5e 5f 5d c3 0f 0b 8d 0a 86 ea

2d c0 e9 14 ff ff ff 0f 0b 8f 0a 86 ea 2d c0 e9 1c ff ff ff <0f> 0b 8e 0a 86 ea 2d c0 e9 04 ff ff ff 55 89 e5 57 56 31 f6 53
<3>subfs: submountd execution failure. Error 11

Think it's too early to party, eh? :)

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#215 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 8 lines
Quoted 5 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

Quoted 8 lines

As an aside, my greatest complaint is that jackd -R doesn't work at all:

JACK: unable to mlock() port buffers: Cannot allocate memory
jack_create_thread: error -1 switching current thread to rt for
inheritance: Unknown error 4294967295
cannot start watchdog thread
cannot load driver module alsa

Forget this. The reason is that realtime-lsm module wasn't being loaded.

Sorry.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#216 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

Not critical, but I'm "consistently" getting stuck while running mkinitrd, both on SMP (SuSE9.1, reiserfs) and UP (Mdk10.1c, ext3). This was happening with U6 too.

Anyone care to confirm?

Some more incidents on 2.6.9-rc5-mm1-RT-U7.0smp:

kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
PREEMPT SMP

Modules linked in: loop nls_iso8859_15 nls_cp860 vfat fat nls_base snd_seq

usbhi
d ehci_hcd uhci_hcd intel_mch_agp agpgart mga snd_usb_usx2y snd_usb_lib snd_rawm
idi snd_seq_device snd_hwdep snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd s
oundcore snd_page_alloc evdev sk98lin w83781d i2c_sensor i2c_isa i2c_i801 i2c_co
re wacom usbcore subfs dm_mod

CPU:    0
EIP:    0060:[<c01e3e5d>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U7.0smp)

EIP is at rwsem_owner_del+0x68/0x8c
eax: f41c0a50 ebx: cb736000 ecx: 00000001 edx: 00000001
esi: 00000001 edi: cdf30218 ebp: cb737fa0 esp: cb737f94
ds: 007b es: 007b ss: 0068 preempt: 00000003
Process loop0 (pid: 23481, threadinfo=cb736000 task=f71ba7d0)

Stack: cdf3021c cdf30000 cdf30218 cb737fc8 c01e42d0 cdf30218 f71ba7d0
c1806cd4
       c1806820 00000282 f8c839aa cdf30000 cdf30448 cb737fec f8c83a0f
f71ba7d0
       ffffffec 00000000 cdf30218 f8c839aa 00000000 00000000 00000000
c01025c9
Call Trace:
 [<c0105235>] show_stack+0xaf/0xb7 (28)
 [<c01053c5>] show_registers+0x168/0x1dd (56)
 [<c01055ce>] die+0x107/0x18f (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)

preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1) .. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1) .. entry 3: _spin_lock_irqsave+0x17/0x70 / (die+0x3f/0x18f) .. entry 4: print_traces+0x16/0x4c / (show_stack+0xaf/0xb7)

Code: 00 e0 ff ff 21 e3 8b 44 8f 18 3b 03 74 2a 83 c1 01 89 d6 39 d1 7c ef

8b 15
60 fa 31 c0 85 d2 74 12 c7 05 60 fa 31 c0 00 00 00 00 <0f> 0b 82 00 0b 96
2e c0
5b 5e 5f 5d c3 8d 56 ff 39 d1 74 08 8b
<6>note: loop0[23481] exited with preempt_count 2

BUG: sleeping function called from invalid context loop0(23481) at
lib/rwsem-gen
eric.c:398
in_atomic():1 [00000002], irqs_disabled():0
 [<c010525b>] dump_stack+0x1e/0x20 (20)
 [<c0118408>] __might_sleep+0xb7/0xca (36)
 [<c02ca11c>] down_write+0x1f/0x184 (44)
 [<c011cfbc>] exit_notify+0x26/0x97f (60)
 [<c011db93>] do_exit+0x27e/0x492 (40)
 [<c0105656>] do_divide_error+0x0/0x12c (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1) .. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1) .. entry 3: print_traces+0x16/0x4c / (dump_stack+0x1e/0x20)

BUG: scheduling while atomic: loop0/0x00000002/23481
caller is do_exit+0x287/0x492
 [<c010525b>] dump_stack+0x1e/0x20 (20)
 [<c02c90d6>] __schedule+0x836/0xc81 (116)
 [<c011db9c>] do_exit+0x287/0x492 (40)
 [<c0105656>] do_divide_error+0x0/0x12c (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1) .. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1) .. entry 3: print_traces+0x16/0x4c / (dump_stack+0x1e/0x20)

Bye now.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 1098228272.12223.1134.camel@thomas

#219 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 9 lines · Thomas Gleixner
Quoted 8 lines · Lee Revell
Quoted 6 lines · Rui Nuno Capela
Quoted 5 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

Quoted 7 lines
Quoted 4 lines

Ingo, did you forget to cc: LKML on the U7 announcement, or is the list just slow today? I checked my mail as well as lkml.org, this does not seem to have made it to the list.

Yes, it's slow. Postings drop in in random order with long delays.

Sorry, I screwed up linux-kernel in the cc: list.

Lee

#220 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

this too is a fixes-only release.

First Ux I try to boot, on install I get this:

WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/scsi/aacraid/aacraid.ko needs unknown symbol __you_cannot_kmalloc_that_much WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_block.ko needs unknown symbol i2o_msg_in_to_virt WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_core.ko needs unknown symbol i2o_msg_in_to_virt WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_core.ko needs unknown symbol i2o_msg_out_to_virt WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_scsi.ko needs unknown symbol i2o_msg_in_to_virt

No luck booting, I get a kernel panic, the last lines printed to the screen are like this (transcribed by hand, there may be errors):

printk+0x17/0x20 (20)
print_preempt_trace+0x51/0xa0 (12)
print_traces+0x1e/0x40 (24)
show_stack+0x70/0x90 (8)
error_code+0x2d/0x38 (20)
down_write_interruptible+0xba/0x278 (52)
scsi_error_handler+0x98/0x1a0 [scsi_mod] (44)
scsi_error_handler+0x0/0x1a0 [scsi_mod] (284)
kernel_thread_helper+0x5/0x18 (8)

preempt count: 04000008
. 8 level deep critical section nesting:
.. entry 1: down_write_interruptible+0x273/0x278 / (0x0) .. entry 2: down_write_interruptible+0x5a/0x278 / (0x0) .. entry 3: __schedule+0x34/0x650 / (0x0)
.. entry 4: __schedule+0xcb/0x650 / (0x0)
.. entry 5: __schedule+0x34/0x650 / (0x0)
.. entry 6: __schedule+0xcb/0x650 / (0x0)
.. entry 7: die+0x36/0x180 / (0x0)
.. entry 8: print_traces+0xd/0x40 / (0x0)
<0> Kernel panic - not syncing: Fatal exception in interrupt

I hope this can be useful...
-- Fernando

#222 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 2 lines · Thomas Gleixner

That's in scsi_error_handler() where a mutex is initialized locked and then acquired again. This triggers the deadlock/correctness check.

Some more fixes

- scsi_error_handler() fix

- device subsystem device_remove locking fix

tglx

drivers/base/bus.c +1 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/base/bus.c 2.6.9-rc4-mm1-RT-U7-work/drivers/base/bus.c
@@ -65,7 +65,7 @@
 static void driver_release(struct kobject * kobj)
 {
 	struct device_driver * drv = to_driver(kobj);
-	up(&drv->unload_sem);
+	complete(&drv->unload_done);
 }
 
 static struct kobj_type ktype_driver = {
include/linux/device.h +1 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/include/linux/device.h 2.6.9-rc4-mm1-RT-U7-work/include/linux/device.h
@@ -102,7 +102,7 @@
 	char			* name;
 	struct bus_type		* bus;
 
-	struct semaphore	unload_sem;
+	struct completion	unload_done;
 	struct kobject		kobj;
 	struct list_head	devices;
 
drivers/base/driver.c +7 -10
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/base/driver.c 2.6.9-rc4-mm1-RT-U7-work/drivers/base/driver.c
@@ -79,14 +79,13 @@
  *	since most of the things we have to do deal with the bus
  *	structures.
  *
- *	The one interesting aspect is that we initialize @drv->unload_sem
- *	to a locked state here. It will be unlocked when the driver
- *	reference count reaches 0.
+ *	We init the completion strcut here. When the reference 
+ *	count reaches zero, complete() is called from bus_release().
  */
 int driver_register(struct device_driver * drv)
 {
 	INIT_LIST_HEAD(&drv->devices);
-	init_MUTEX_LOCKED(&drv->unload_sem);
+	init_completion(&drv->unload_done);
 	return bus_add_driver(drv);
 }
 
@@ -97,18 +96,16 @@
  *
  *	Again, we pass off most of the work to the bus-level call.
  *
- *	Though, once that is done, we attempt to take @drv->unload_sem.
- *	This will block until the driver refcount reaches 0, and it is
- *	released. Only modular drivers will call this function, and we
+ *	Though, once that is done, we wait until the driver refcount 
+ *	reaches 0, and complete() is called in bus_release().
+ *	Only modular drivers will call this function, and we
  *	have to guarantee that it won't complete, letting the driver
  *	unload until all references are gone.
  */
-
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	down(&drv->unload_sem);
-	up(&drv->unload_sem);
+	wait_for_completion(&drv->unload_done);
 }
 
 /**
drivers/scsi/hosts.c +1 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/hosts.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/hosts.c
@@ -149,7 +149,7 @@
 		DECLARE_COMPLETION(sem);
 		shost->eh_notify = &sem;
 		shost->eh_kill = 1;
-		up(shost->eh_wait);
+		wake_up(shost->eh_wait);
 		wait_for_completion(&sem);
 		shost->eh_notify = NULL;
 	}
drivers/scsi/scsi_error.c +8 -12
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/scsi_error.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/scsi_error.c
@@ -49,7 +49,7 @@
 void scsi_eh_wakeup(struct Scsi_Host *shost)
 {
 	if (shost->host_busy == shost->host_failed) {
-		up(shost->eh_wait);
+		wake_up(shost->eh_wait);
 		SCSI_LOG_ERROR_RECOVERY(5,
 				printk("Waking error handler thread\n"));
 	}
@@ -1599,9 +1599,8 @@
 {
 	struct Scsi_Host *shost = (struct Scsi_Host *) data;
 	int rtn;
-	DECLARE_MUTEX(sem);
+	DECLARE_WAIT_QUEUE_HEAD(eh_wait);
 
-	init_MUTEX_LOCKED(&sem);
 	/*
 	 *    Flush resources
 	 */
@@ -1610,7 +1609,7 @@
 
 	current->flags |= PF_NOFREEZE;
 
-	shost->eh_wait = &sem;
+	shost->eh_wait = &eh_wait;
 	shost->ehandler = current;
 
 	/*
@@ -1632,15 +1631,12 @@
 						  " sleeping\n",shost->host_no));
 
 		/*
-		 * Note - we always use down_interruptible with the semaphore
-		 * even if the module was loaded as part of the kernel.  The
-		 * reason is that down() will cause this thread to be counted
-		 * in the load average as a running process, and down
-		 * interruptible doesn't.  Given that we need to allow this
-		 * thread to die if the driver was loaded as a module, using
-		 * semaphores isn't unreasonable.
+		 * Wait, until somebody decides to wake us due to an error
+		 * or because we should be killed
 		 */
-		down_interruptible(&sem);
+		wait_event_interruptible(eh_wait, shost->eh_kill ||
+				(shost->host_busy == shost->host_failed)); 
+	
 		if (shost->eh_kill)
 			break;
 
include/scsi/scsi_host.h +1 -1
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/include/scsi/scsi_host.h 2.6.9-rc4-mm1-RT-U7-work/include/scsi/scsi_host.h
@@ -396,7 +396,7 @@
 
 	struct list_head	eh_cmd_q;
 	struct task_struct    * ehandler;  /* Error recovery thread. */
-	struct semaphore      * eh_wait;   /* The error recovery thread waits
+	wait_queue_head_t     * eh_wait;   /* The error recovery thread waits
 					      on this. */
 	struct completion     * eh_notify; /* wait for eh to begin or end */
 	struct semaphore      * eh_action; /* Wait for specific actions on the
#223 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 9 lines · Thomas Gleixner
Quoted 2 lines · Thomas Gleixner

That's in scsi_error_handler() where a mutex is initialized locked and then acquired again. This triggers the deadlock/correctness check.

Some more fixes

- scsi_error_handler() fix

- device subsystem device_remove locking fix

thanks, i've applied these. The block/loop.c assert reported by Rui seems to be a similar problem too.

Ingo

#224 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 5 lines · Ingo Molnar
Quoted 2 lines

- scsi_error_handler() fix
- device subsystem device_remove locking fix

thanks, i've applied these. The block/loop.c assert reported by Rui seems to be a similar problem too.

Yep, it's all the same scheme. Most of the offending code uses MUTEX_LOCKED in an init function and plays the down, and up from a different context game, which triggers the deadlock/owner verify. Not hard to fix, but at some places it takes a bit, until you see the intention of the driver hacker.

The most surprising one was in driver/base. I did not expect that new 2.5/6 code uses those tricks too.

Fixes for aic7xxx and sym53c8xx_2 attached.

tglx

drivers/scsi/aic7xxx/aic7xxx_osm.c +37 -47
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1873,9 +1873,10 @@
 	ahc->platform_data->completeq_timer.data = (u_long)ahc;
 	ahc->platform_data->completeq_timer.function =
 	    (ahc_linux_callback_t *)ahc_linux_thread_run_complete_queue;
-	init_MUTEX_LOCKED(&ahc->platform_data->eh_sem);
-	init_MUTEX_LOCKED(&ahc->platform_data->dv_sem);
-	init_MUTEX_LOCKED(&ahc->platform_data->dv_cmd_sem);
+	init_waitqueue_head(&ahc->platform_data->eh_sem);
+	init_waitqueue_head(&ahc->platform_data->dv_sem);
+	init_waitqueue_head(&ahc->platform_data->dv_cmd_sem);
+	init_completion(&ahc->platform_data->dv_exit);
 	tasklet_init(&ahc->platform_data->runq_tasklet, ahc_runq_tasklet,
 		     (unsigned long)ahc);
 	ahc->seltime = (aic7xxx_seltime & 0x3) << 4;
@@ -2156,7 +2157,7 @@
 		ahc_linux_freeze_simq(ahc);
 
 		/* Wake up the DV kthread */
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 }
 
@@ -2169,39 +2170,22 @@
 	if (ahc->platform_data->dv_pid != 0) {
 		ahc->platform_data->flags |= AHC_DV_SHUTDOWN;
 		ahc_unlock(ahc, &s);
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 
-		/*
-		 * Use the eh_sem as an indicator that the
-		 * dv thread is exiting.  Note that the dv
-		 * thread must still return after performing
-		 * the up on our semaphore before it has
-		 * completely exited this module.  Unfortunately,
-		 * there seems to be no easy way to wait for the
-		 * exit of a thread for which you are not the
-		 * parent (dv threads are parented by init).
-		 * Cross your fingers...
-		 */
-		down(&ahc->platform_data->eh_sem);
-
-		/*
-		 * Mark the dv thread as already dead.  This
-		 * avoids attempting to kill it a second time.
-		 * This is necessary because we must kill the
-		 * DV thread before calling ahc_free() in the
-		 * module shutdown case to avoid bogus locking
-		 * in the SCSI mid-layer, but we ahc_free() is
-		 * called without killing the DV thread in the
-		 * instance detach case, so ahc_platform_free()
-		 * calls us again to verify that the DV thread
-		 * is dead.
-		 */
-		ahc->platform_data->dv_pid = 0;
+		/* Wait until the thread has exited */
+		wait_for_completion(&ahc->platform_data->dv_exit);
 	} else {
 		ahc_unlock(ahc, &s);
 	}
 }
 
+#define AHC_WAIT_FOR_WORK \
+	(ahc->platform_data->flags & (AHC_DV_SHUTDOWN | AHC_DV_ACTIVE))
+#define AHC_WAIT_FOR_SIMQ_EMPTY \
+	(!(ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_EMPTY))
+#define AHC_WAIT_FOR_SIMQ_RELEASE \
+	(!(ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_RELEASE))
+
 static int
 ahc_linux_dv_thread(void *data)
 {
@@ -2235,11 +2219,9 @@
 	unlock_kernel();
 
 	while (1) {
-		/*
-		 * Use down_interruptible() rather than down() to
-		 * avoid inclusion in the load average.
-		 */
-		down_interruptible(&ahc->platform_data->dv_sem);
+		/* Wait for work */
+		wait_event_interruptible(ahc->platform_data->dv_sem,
+					 AHC_WAIT_FOR_WORK);
 
 		/* Check to see if we've been signaled to exit */
 		ahc_lock(ahc, &s);
@@ -2262,7 +2244,8 @@
 		while (LIST_FIRST(&ahc->pending_scbs) != NULL) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_EMPTY;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_EMPTY);
 			ahc_lock(ahc, &s);
 		}
 
@@ -2273,7 +2256,8 @@
 		while (AHC_DV_SIMQ_FROZEN(ahc) == 0) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_RELEASE;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_RELEASE);
 			ahc_lock(ahc, &s);
 		}
 		ahc_unlock(ahc, &s);
@@ -2291,7 +2275,9 @@
 		 */
 		ahc_linux_release_simq((u_long)ahc);
 	}
-	up(&ahc->platform_data->eh_sem);
+	/* Mark it as gone */
+	ahc->platform_data->dv_pid = 0;
+	complete(&ahc->platform_data->dv_exit);
 	return (0);
 }
 
@@ -2454,7 +2440,9 @@
 #else
 		spin_unlock_irqrestore(&io_request_lock, s);
 #endif
-		down_interruptible(&ahc->platform_data->dv_cmd_sem);
+		wait_event_interruptible(ahc->platform_data->dv_cmd_sem,
+					 !timer_pending(&cmd->eh_timeout));
+					 
 		/*
 		 * Wait for the SIMQ to be released so that DV is the
 		 * only reason the queue is frozen.
@@ -2463,7 +2451,8 @@
 		while (AHC_DV_SIMQ_FROZEN(ahc) == 0) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_RELEASE;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_RELEASE);
 			ahc_lock(ahc, &s);
 		}
 		ahc_unlock(ahc, &s);
@@ -3404,7 +3393,7 @@
 #endif
 
 	/* Wake up the state machine */
-	up(&ahc->platform_data->dv_cmd_sem);
+	wake_up(&ahc->platform_data->dv_cmd_sem);
 }
 
 static void
@@ -4164,7 +4153,7 @@
 			ahc_set_transaction_status(scb, CAM_CMD_TIMEOUT);
 		if ((ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE) != 0) {
 			ahc->platform_data->flags &= ~AHC_UP_EH_SEMAPHORE;
-			up(&ahc->platform_data->eh_sem);
+			wake_up(&ahc->platform_data->eh_sem);
 		}
 	}
 
@@ -4174,7 +4163,7 @@
 	if ((ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_EMPTY) != 0
 	 && LIST_FIRST(&ahc->pending_scbs) == NULL) {
 		ahc->platform_data->flags &= ~AHC_DV_WAIT_SIMQ_EMPTY;
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 		
 }
@@ -4563,7 +4552,7 @@
 	ahc_lock(ahc, &s);
 	if ((ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE) != 0) {
 		ahc->platform_data->flags &= ~AHC_UP_EH_SEMAPHORE;
-		up(&ahc->platform_data->eh_sem);
+		wake_up(&ahc->platform_data->eh_sem);
 	}
 	ahc_unlock(ahc, &s);
 }
@@ -4600,7 +4589,7 @@
 	if (AHC_DV_SIMQ_FROZEN(ahc)
 	 && ((ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_RELEASE) != 0)) {
 		ahc->platform_data->flags &= ~AHC_DV_WAIT_SIMQ_RELEASE;
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 	ahc_schedule_runq(ahc);
 	ahc_unlock(ahc, &s);
@@ -4952,7 +4941,8 @@
 		timer.function = ahc_linux_sem_timeout;
 		add_timer(&timer);
 		printf("Recovery code sleeping\n");
-		down(&ahc->platform_data->eh_sem);
+		wait_event(ahc->platform_data->eh_sem,
+			   !(ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE));
 		printf("Recovery code awake\n");
         	ret = del_timer_sync(&timer);
 		if (ret == 0) {
drivers/scsi/aic7xxx/aic7xxx_osm.h +6 -4
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.h 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.h
@@ -534,11 +534,13 @@
 	pid_t			 dv_pid;
 	struct timer_list	 completeq_timer;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
-	struct semaphore	 dv_sem;
-	struct semaphore	 dv_cmd_sem;	/* XXX This needs to be in
-						 * the target struct
+	wait_queue_head_t	 eh_sem;
+	wait_queue_head_t	 dv_sem;
+	wait_queue_head_t	 dv_cmd_sem;	/* XXX This needs to be in
+   						 * the target struct
 						 */
+	struct completion	 dv_exit;
+	
 	struct scsi_device	*dv_scsi_dev;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHC_LINUX_NOIRQ	((uint32_t)~0)
drivers/scsi/sym53c8xx_2/sym_glue.c +4 -4
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/sym53c8xx_2/sym_glue.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -135,7 +135,7 @@
  *  It is allocated on the eh thread stack.
  */
 struct sym_eh_wait {
-	struct semaphore sem;
+	struct completion done;
 	struct timer_list timer;
 	void (*old_done)(struct scsi_cmnd *);
 	int to_do;
@@ -798,7 +798,7 @@
 
 	/* Wake up the eh thread if it wants to sleep */
 	if (ep->to_do == SYM_EH_DO_WAIT)
-		up(&ep->sem);
+		complete(&ep->done);
 }
 
 /*
@@ -858,7 +858,7 @@
 	case SYM_EH_DO_IGNORE:
 		break;
 	case SYM_EH_DO_WAIT:
-		init_MUTEX_LOCKED(&ep->sem);
+		init_completion(&ep->done);
 		/* fall through */
 	case SYM_EH_DO_COMPLETE:
 		ep->old_done = cmd->scsi_done;
@@ -909,7 +909,7 @@
 		ep->timed_out = 1;	/* Be pessimistic for once :) */
 		add_timer(&ep->timer);
 		spin_unlock_irq(np->s.host->host_lock);
-		down(&ep->sem);
+		wait_for_completion(&ep->done);
 		spin_lock_irq(np->s.host->host_lock);
 		if (ep->timed_out)
 			sts = -2;
#225 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

Quoted 5 lines · Thomas Gleixner

Yep, it's all the same scheme. Most of the offending code uses MUTEX_LOCKED in an init function and plays the down, and up from a different context game, which triggers the deadlock/owner verify. Not hard to fix, but at some places it takes a bit, until you see the intention of the driver hacker.

the NFS ones seemed to be the least clear ones. I'm glad you converted those already :-)

Quoted 2 lines

The most surprising one was in driver/base. I did not expect that new 2.5/6 code uses those tricks too.

it is not strictly a bug, but that technique was discouraged for years - completions are cleaner and faster for that purpose anyway. (they were designed for what in the semaphore case is the slowpath.)

Quoted 1 line

Fixes for aic7xxx and sym53c8xx_2 attached.

Applied. The sym53c8xx_2 looks good. aic7xxx is good too except for a minor cleanup issue: i've changed all _sem symbols to be _done symbols. It's not a semaphore anymore, lets avoid the namespace-rotting effect. I've put these into -U8 so anyone hitting aic7xxx or sym53c8xx_2 should re-download the -U8 patch. (others who have already downloaded it should not bother.)

Ingo

#226 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7

In reply to Ingo Molnar
Quoted 3 lines · Ingo Molnar

i have released the -U7 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

OK, this one boots but Gnome does not start. It hangs at "Session Manager". The system does not hang, but I never get to my desktop. Nothing useful in the logs.

While this was going on I switched to a text console and noticed that if I enabled/ Caps Lock at just the right moment then _all_ text output (LOGIN, PASSWORD, etc) would be in caps. Toggling it a few times seemed to get rid of the problem.

Any particular debug options I should try?

Lee

#227 lore raw

PATCH 1/1 Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

this too is a fixes-only release. It includes the many semaphore-abuse and sleep_on() fixes/improvements from Thomas Gleixner, and it also includes a couple of semaphore related fixes.

I believe the semaphore fixes should resolve a number of the deadlocks reported for -U7.

In particular it seems the only sane and reliable way to convert RCU locking was to allow the following semantics for rwsems: allow reads to nest, and allow self-read-recursion of a self-write-held semaphore. My current implementation for this allows semaphore unfairness, but that can be fixed later on. Most importantly, the RCU to RT-locking conversions are much more automatic now and map nicely to what the code is doing upstream. Most of the time they involve a conversion of a spinlock or semaphore into a rwlock or rwsem. The old code maps to new code almost automatically, the only manual work needed was to associate the rcu_read_lock() with the writers-lock that it excludes against, which is a pretty clear (but not automatic, and hence not automatable) decision. This way i could convert some more networking code, and simplify the older changes and hopefully get rid of some deadlocks. The locking API is still not in its final form, but it's getting closer.

Changes since -U7:

- deadlock fix: sysfs/driver-base semaphore fixes from Thomas Gleixner

- deadlock fix: scsi semaphore fixes from Thomas Gleixner

- NFS sleep_on() fixes from Thomas Gleixner

- rawmidid.c sleep_on() fix from Thomas Gleixner

- [ i've added more wait_for_completion_*() primitives, to ease conversion of other semaphore-(ab-)using code. ]

- make rwsems self-recursive

- RCU lock conversion: convert rtnl_sem RCU use.

- netfilter deadlock fix - clean up RCU locking.

to create a -U8 tree from scratch, the patching order is:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
+ http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
+ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
+ http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Ingo

#228 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines

Changes since -U7:

- fix block-loopback assert reported by Mark H Johnson, Matthew L Foster and Rui Nuno Capela. (usually triggers during 'make install' of a kernel compile.)

Ingo

#229 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 8 lines · Ingo Molnar
Quoted 3 lines

Changes since -U7:

- fix block-loopback assert reported by Mark H Johnson, Matthew L Foster and Rui Nuno Capela. (usually triggers during 'make install' of a kernel compile.)

Is this fix already on U8 ? I don't seem to get out of mkinitrd (which is triggered by kernel make install).

OTOH, still on my laptop (P4/UP) I'm getting this very often:

RTNL: assertion failed at net/ipv4/devinet.c (1049)

 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<c02afa2b>] inet_dump_ifaddr+0x135/0x13a (52)
 [<c027a533>] rtnetlink_dump_all+0x92/0xaa (40)
 [<c028117f>] netlink_dump+0x6c/0x211 (56)
 [<c0280f97>] netlink_recvmsg+0x209/0x21b (92)
 [<c0268a40>] sock_recvmsg+0xcc/0xf0 (248)
 [<c026a4cc>] sys_recvmsg+0x110/0x1fb (284)
 [<c026a628>] sys_socketcall+0x71/0x234 (68)
 [<c01040a9>] sysenter_past_esp+0x52/0x71 (-8124)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x16/0x4a / (dump_stack+0x1e/0x20)

And I also found this once:

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: realtime commoncap snd_seq_oss snd_seq_midi_event

snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs p80211 ds yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore thermal processor fan button battery ac

CPU:    0
EIP:    0060:[<c01b7e30>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-rc4-mm1-RT-U8.0)

EIP is at up_write+0x1d4/0x202
eax: d4edc000 ebx: e003f967 ecx: d4eb8d40 edx: dee04020
esi: de9b4214 edi: de9b443c ebp: d4eddfcc esp: d4eddfac
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process loop0 (pid: 6672, threadinfo=d4edc000 task=d4eb8d40)

Stack: c0113b01 00000001 c0384d90 c0384d60 00000282 e003f967 de9b4000
de9b443c
       d4eddfec e003f9c8 d4eb8d40 ffffffec 00000000 e003f967 00000000
00000000
       00000000 c0102305 de9b4000 00000000 00000000
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e003f9c8>] loop_thread+0x61/0x11b [loop] (32)
 [<c0102305>] kernel_thread_helper+0x5/0xb (722608148)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d) .. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 f1 af f5 ff e9 35 ff ff ff 0f 0b a5 00 43 e4

2c c0 e9 da fe ff ff 0f 0b a4 00 43 e4 2c c0 e9 c4 fe ff ff <0f> 0b 56 02 cf 70 2d c0 e9 3c fe ff ff e8 d7 56 10 00 e9 22 ff

(config.gz is attached)

Bye now.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#230 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 5 lines · Rui Nuno Capela
Quoted 4 lines · Ingo Molnar
Quoted 3 lines

Changes since -U7:

Quoted 7 lines
Quoted 4 lines

- fix block-loopback assert reported by Mark H Johnson, Matthew L Foster and Rui Nuno Capela. (usually triggers during 'make install' of a kernel compile.)

Is this fix already on U8 ? I don't seem to get out of mkinitrd (which is triggered by kernel make install).

please re-download -U8, i've updated it a couple of minutes after uploading it, but apparently not fast enough :-| Sorry!

Quoted 3 lines

OTOH, still on my laptop (P4/UP) I'm getting this very often:

RTNL: assertion failed at net/ipv4/devinet.c (1049)

yeah - this too was an oversight i fixed in the latest upload.

Quoted 6 lines
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!

 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e003f9c8>] loop_thread+0x61/0x11b [loop] (32)
 [<c0102305>] kernel_thread_helper+0x5/0xb (722608148)

yes, this is the loopback fix. Please-retry with the latest patch.

Ingo

#231 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 8 lines · Ingo Molnar
Quoted 6 lines · Rui Nuno Capela
Quoted 5 lines

- fix block-loopback assert reported by Mark H Johnson, Matthew L Foster and Rui Nuno Capela. (usually triggers during 'make install' of a kernel compile.)

Quoted 6 lines
Quoted 2 lines

Is this fix already on U8 ? I don't seem to get out of mkinitrd (which is triggered by kernel make install).

please re-download -U8, i've updated it a couple of minutes after uploading it, but apparently not fast enough :-| Sorry!

OK. No problem.... and yes, mkinitrd (make install) works again.

Quoted 5 lines
Quoted 3 lines

OTOH, still on my laptop (P4/UP) I'm getting this very often:

RTNL: assertion failed at net/ipv4/devinet.c (1049)

yeah - this too was an oversight i fixed in the latest upload.

I don't think so. I still see plenty of those here.

Is there an even more recent U8? I think you should consider add some dot numbering to each of the uploads... ;)

Bye now.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#232 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 5 lines · Rui Nuno Capela
Quoted 3 lines

please re-download -U8, i've updated it a couple of minutes after uploading it, but apparently not fast enough :-| Sorry!

OK. No problem.... and yes, mkinitrd (make install) works again.

good.

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

RTNL: assertion failed at net/ipv4/devinet.c (1049)

yeah - this too was an oversight i fixed in the latest upload.

I don't think so. I still see plenty of those here.

Is there an even more recent U8? I think you should consider add some dot numbering to each of the uploads... ;)

indeed this most likely means there's a newer update :-| Please double-check that the one you have is:

 $ md5sum realtime-preempt-2.6.9-rc4-mm1-U8
 b59ae00ca0f45f545519348113af5c4f  realtime-preempt-2.6.9-rc4-mm1-U8

Ingo

#233 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Ingo Molnar
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

RTNL: assertion failed at net/ipv4/devinet.c (1049)

yeah - this too was an oversight i fixed in the latest upload.

I don't think so. I still see plenty of those here.

Quoted 9 lines
Quoted 2 lines

Is there an even more recent U8? I think you should consider add some dot numbering to each of the uploads... ;)

indeed this most likely means there's a newer update :-| Please double-check that the one you have is:

 $ md5sum realtime-preempt-2.6.9-rc4-mm1-U8
 b59ae00ca0f45f545519348113af5c4f  realtime-preempt-2.6.9-rc4-mm1-U8

That was it. Thanks.

Now's some bad news:

I getting the dump below, this time while plugging a flash memory stick, but right after that the system starts to behave preety bad and increasingly unresponsive. An hard-boot is almost the end of the (short) story :(

(e.g. running jackd also hoses the complete system in no reproducible amount of time--sometimes short, other times long, like a random time-bomb).

ohci_hcd 0000:00:0f.0: wakeup
usb 2-1: new full speed USB device using address 2 Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: usb_storage vfat fat udf isofs nls_base realtime

commoncap snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs p80211 ds yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore thermal processor fan button battery ac

CPU:    0
EIP:    0060:[<c01b7e30>]    Not tainted VLI
EFLAGS: 00010206   (2.6.9-rc4-mm1-RT-U8.3)

EIP is at up_write+0x1d4/0x202
eax: d2b2a000 ebx: 00000292 ecx: d2afe980 edx: d2ad4f40
esi: d7b83b24 edi: dcb21000 ebp: d2b2bd6c esp: d2b2bd4c
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process usb-stor (pid: 6699, threadinfo=d2b2a000 task=d2ad48b0)

Stack: d2ad48b0 d2b2bd78 c02bea7f 00000001 d2ad48b0 00000292 d2afe980
dcb21000
       d2b2bd84 e01ca139 d2afe980 d2b2bd84 00000292 dcb21138 d2b2bdac
c022ed18
       d2afe980 c022ef1c c0231679 00000000 d2afe9d4 d2afe980 d2aa3800
dcb21000
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e01ca139>] queuecommand+0x70/0x7c [usb_storage] (24)
 [<c022ed18>] scsi_dispatch_cmd+0x168/0x218 (40)
 [<c02342ed>] scsi_request_fn+0x1ee/0x42b (52)
 [<c0205612>] blk_insert_request+0xcd/0xfb (44)
 [<c0232f4f>] scsi_insert_special_req+0x3b/0x3f (28)
 [<c0233181>] scsi_wait_req+0x61/0x94 (60)
 [<c023529c>] scsi_probe_lun+0x8e/0x240 (68)
 [<c023588f>] scsi_probe_and_add_lun+0xb0/0x1be (48)
 [<c0236015>] scsi_scan_target+0xa4/0x123 (60)
 [<c0236121>] scsi_scan_channel+0x8d/0xa4 (48)
 [<c02361b1>] scsi_scan_host_selected+0x79/0xd4 (44)
 [<c023623d>] scsi_scan_host+0x31/0x33 (28)
 [<e01cccbd>] usb_stor_scan_thread+0x144/0x155 [usb_storage] (96)
 [<c0102305>] kernel_thread_helper+0x5/0xb (760037396)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d) .. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 f1 af f5 ff e9 35 ff ff ff 0f 0b a5 00 e3 e8

2c c0 e9 da fe ff ff 0f 0b a4 00 e3 e8 2c c0 e9 c4 fe ff ff <0f> 0b 56 02 6f 75 2d c0 e9 3c fe ff ff e8 7f 5b 10 00 e9 22 ff

Bye.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#234 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

I'm getting these BUGs when I use netconsole with Real-Time Preemption (but netconsole works):

kjournald starting. Commit interval 5 seconds

BUG: sleeping function called from invalid context kjournald(775) at kernel/mutex.c:25
in_atomic():0 [00000000], irqs_disabled():1
 [<c0105fbe>] dump_stack+0x1e/0x20 (20)
 [<c01194d8>] __might_sleep+0xb8/0xd0 (36)
 [<c0130bc0>] _mutex_lock+0x20/0x40 (20)
 [<c02675f7>] netpoll_send_skb+0x37/0xc0 (28)
 [<c0231081>] write_msg+0x41/0x60 (36)
 [<c011c208>] __call_console_drivers+0x58/0x60 (32)
 [<c011c326>] call_console_drivers+0x96/0x140 (40)
 [<c011c6e1>] release_console_sem+0x71/0x100 (36)
 [<c011c5b6>] vprintk+0x116/0x180 (36)
 [<c011c498>] printk+0x18/0x20 (16)
 [<c01a31af>] kjournald+0x8f/0x250 (140)
 [<c01032d1>] kernel_thread_helper+0x5/0x14 (141484052)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x18/0x50 / (dump_stack+0x1e/0x20)

EXT3 FS on hda8, <3>BUG: sleeping function called from invalid context mount(786) at kernel/mutex.c:25 in_atomic():0 [00000000], irqs_disabled():1

 [<c0105fbe>] dump_stack+0x1e/0x20 (20)
 [<c01194d8>] __might_sleep+0xb8/0xd0 (36)
 [<c0130bc0>] _mutex_lock+0x20/0x40 (20)
 [<c02675f7>] netpoll_send_skb+0x37/0xc0 (28)
 [<c0231081>] write_msg+0x41/0x60 (36)
 [<c011c208>] __call_console_drivers+0x58/0x60 (32)
 [<c011c302>] call_console_drivers+0x72/0x140 (40)
 [<c011c6e1>] release_console_sem+0x71/0x100 (36)
 [<c011c5b6>] vprintk+0x116/0x180 (36)
 [<c011c498>] printk+0x18/0x20 (16)
 [<c01989f2>] ext3_setup_super+0xd2/0x1c0 (80)
 [<c019a5ed>] ext3_remount+0x12d/0x190 (48)
 [<c015d9b0>] do_remount_sb+0xa0/0xf0 (32)
 [<c0173c6d>] do_remount+0x6d/0xc0 (36)
 [<c01745fb>] do_mount+0x19b/0x1b0 (116)
 [<c01749e7>] sys_mount+0x97/0xe0 (48)
 [<c010518f>] syscall_call+0x7/0xb (-8124)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x18/0x50 / (dump_stack+0x1e/0x20)

internal journal

I have hacked the sk98lin driver to support netpoll (I sent the patch to netdev), so maybe I did something wrong and these BUGs are my own fault.

Does anybody else use netconsole with Real-Time Preemption?

Michal

#235 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 2 lines · Michal Schmidt

I'm getting these BUGs when I use netconsole with Real-Time Preemption (but netconsole works):

you are getting them because interrupts get disabled somewhere in the path. Do your changes perhaps introduce a local_irq_save() or local_irq_disable()?

(in PREEMPT_REALTIME spin_lock_irq*() does not disable interrupts for mutex-based spinlocks, so the only way to get irqs disabled is explicitly.)

Ingo

#236 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Ingo Molnar
Quoted 2 lines · Michal Schmidt

I'm getting these BUGs when I use netconsole with Real-Time Preemption (but netconsole works):

you are getting them because interrupts get disabled somewhere in the path. Do your changes perhaps introduce a local_irq_save() or local_irq_disable()?

I'm attaching my sk98lin patch. It uses disable_irq(). It's inspired by 8139too.

Quoted 5 lines

(in PREEMPT_REALTIME spin_lock_irq*() does not disable interrupts for mutex-based spinlocks, so the only way to get irqs disabled is explicitly.)

Ingo

Michal

drivers/net/sk98lin/skge.c +18 -0
diff -Nurp linux-2.6.9/drivers/net/sk98lin/skge.c linux-2.6.9-mich/drivers/net/sk98lin/skge.c
@@ -1126,6 +1126,21 @@ SK_U32		IntSrc;		/* interrupts source re
 		return SkIsrRetHandled;
 } /* SkGeIsrOnePort */
 
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/**
+ * SkGePollController - polling receive, for netconsole
+ * @dev: network device
+ *
+ * Polling receive - used by netconsole and other diagnostic tools
+ * to allow network i/o with interrupts disabled.
+ */
+static void SkGePollController(struct net_device *dev)
+{
+	disable_irq(dev->irq);
+	SkGeIsr(dev->irq, dev, NULL);
+	enable_irq(dev->irq);
+}
+#endif
 
 /****************************************************************************
  *
@@ -4960,6 +4975,9 @@ static int __devinit skge_probe_one(stru
 	dev->set_mac_address =	&SkGeSetMacAddr;
 	dev->do_ioctl =		&SkGeIoctl;
 	dev->change_mtu =	&SkGeChangeMtu;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	dev->poll_controller =	&SkGePollController;
+#endif
 	dev->flags &= 		~IFF_RUNNING;
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
#237 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 6 lines · Michal Schmidt
Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Michal Schmidt

I'm getting these BUGs when I use netconsole with Real-Time Preemption (but netconsole works):

Quoted 7 lines
Quoted 4 lines

you are getting them because interrupts get disabled somewhere in the path. Do your changes perhaps introduce a local_irq_save() or local_irq_disable()?

I'm attaching my sk98lin patch. It uses disable_irq(). It's inspired by 8139too.

disable_irq() should work fine though. (it doesnt disable local interrupts, it only disables that particular irq line.) So something else disabled interrupts - ah, netconsole.c itself. Does the patch below fix things up for you?

Ingo

drivers/net/netconsole.c renamed from drivers/net/netconsole.c.orig +4 -0
@@ -73,7 +73,9 @@ static void write_msg(struct console *co
 	if (!np.dev)
 		return;
 
+#ifndef CONFIG_PREEMPT_REALTIME
 	local_irq_save(flags);
+#endif
 
 	for(left = len; left; ) {
 		frag = min(left, MAX_PRINT_CHUNK);
@@ -82,7 +84,9 @@ static void write_msg(struct console *co
 		left -= frag;
 	}
 
+#ifndef CONFIG_PREEMPT_REALTIME
 	local_irq_restore(flags);
+#endif
 }
 
 static struct console netconsole = {
#238 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Ingo Molnar

disable_irq() should work fine though. (it doesnt disable local interrupts, it only disables that particular irq line.) So something else disabled interrupts - ah, netconsole.c itself. Does the patch below fix things up for you?

Ingo
[patch snipped]

That patch was not enough. The BUGs were still showing up the same as before.
I tried to debug it myself. I've found an interesting thing in kernel/printk.c:release_console_sem(). There is the following sequence:

  spin_lock_irqsave(&logbuf_lock, flags);
  /* ... some code ... */
  spin_unlock(&logbuf_lock);
  call_console_drivers(...);
  local_irq_restore(flags);

I know very little about locking, but I didn't like this two-phased unlock. So I replaced it with a single spin_unlock_irqrestore. Patch attached.
I'm almost certain that there is a reason for the two-phased unlocking and that this patch will break something, but so far it works for me. netconsole now works without complaining.

Michal

kernel/printk.c +1 -2
diff -Nurp linux-2.6.9-rc4-mm1-RT-U8/kernel/printk.c linux-2.6.9-rc4-mm1-RT-U8-m/kernel/printk.c
@@ -646,9 +646,8 @@ void release_console_sem(void)
 		_con_start = con_start;
 		_log_end = log_end;
 		con_start = log_end;		/* Flush */
-		spin_unlock(&logbuf_lock);
+		spin_unlock_irqrestore(&logbuf_lock, flags);
 		call_console_drivers(_con_start, _log_end);
-		local_irq_restore(flags);
 	}
 	console_locked = 0;
 	console_may_schedule = 0;
#239 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · Michal Schmidt

That patch was not enough. The BUGs were still showing up the same as before. I tried to debug it myself. I've found an interesting thing in kernel/printk.c:release_console_sem(). There is the following sequence:

  spin_lock_irqsave(&logbuf_lock, flags);
  /* ... some code ... */
  spin_unlock(&logbuf_lock);
  call_console_drivers(...);
  local_irq_restore(flags);
Quoted 5 lines

I know very little about locking, but I didn't like this two-phased unlock. So I replaced it with a single spin_unlock_irqrestore. Patch attached. I'm almost certain that there is a reason for the two-phased unlocking and that this patch will break something, but so far it works for me. netconsole now works without complaining.

ah, indeed. Note that this is still not enough - please try to add a local_irq_enable() to netconsole.c's console-write function - does that fix it equally well for you?

the reason is that if we crash within an irqs-off section then netconsole will still be called with interrupts disabled and will trigger the assert.

Ingo

#240 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Ingo Molnar

ah, indeed. Note that this is still not enough - please try to add a local_irq_enable() to netconsole.c's console-write function - does that fix it equally well for you?

the reason is that if we crash within an irqs-off section then netconsole will still be called with interrupts disabled and will trigger the assert.

i've added your patch to my tree, plus the extra local_irq_enable(), this should also fix fbcon - so no changes needed to netconsole.c. All of these problems will go away if/when the console code goes away from raw spinlocks.

Ingo

#241 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Ingo Molnar
Quoted 4 lines · Ingo Molnar

ah, indeed. Note that this is still not enough - please try to add a local_irq_enable() to netconsole.c's console-write function - does that fix it equally well for you?

Quoted 8 lines
Quoted 3 lines

the reason is that if we crash within an irqs-off section then netconsole will still be called with interrupts disabled and will trigger the assert.

i've added your patch to my tree, plus the extra local_irq_enable(), this should also fix fbcon - so no changes needed to netconsole.c. All of these problems will go away if/when the console code goes away from raw spinlocks.

actually ... i think i'll add the local_irq_enable() to netconsole.c and fbcon, that way the VGA and serial consoles can still keep interrupts disabled. That could make the difference between a debuggable and undebuggable crash ...

Ingo

#242 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 1 line · On Wed, 20 Oct 2004 11:45:08 +0200 Ingo Molnar <[email protected]> wrote:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Hi,

i just wanted to let you know that with U8 i still experience the "pauses" i reported on U6, too. I would guess that it's some scheduler thing as jackd running SCHED_FIFO and all its clients (at least the audio threads running SCHED_FIFO) are not affected by the pauses (i don't see any xruns from jackd and audio processing happily goes along without audible dropouts).

Also it seems that /proc/sys/kernel/trace_enabled == 1 is not the only thing being able to trigger the pauses. With U6 i also experienced them with trace_enabled == 0. I have to add though that it took quite a while for them to kick in (hours) after setting trace_enabled to 0. So my conclusion is that trace_enabled == 1 just increases the probability of such pauses by several magnitudes (with 1 i get about one of these pauses per 2-10 minutes, with 0 it took several hours for the first pause to occur and then they stayed less frequent than with 1).

Ah and i forgot: dmesg -n 1 does not help..

flo

#243 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 6 lines · Florian Schmidt

i just wanted to let you know that with U8 i still experience the "pauses" i reported on U6, too. I would guess that it's some scheduler thing as jackd running SCHED_FIFO and all its clients (at least the audio threads running SCHED_FIFO) are not affected by the pauses (i don't see any xruns from jackd and audio processing happily goes along without audible dropouts).

ok.

Quoted 9 lines

Also it seems that /proc/sys/kernel/trace_enabled == 1 is not the only thing being able to trigger the pauses. With U6 i also experienced them with trace_enabled == 0. I have to add though that it took quite a while for them to kick in (hours) after setting trace_enabled to 0. So my conclusion is that trace_enabled == 1 just increases the probability of such pauses by several magnitudes (with 1 i get about one of these pauses per 2-10 minutes, with 0 it took several hours for the first pause to occur and then they stayed less frequent than with 1).

i dont think it's caused by trace_enabled - the trace you sent last time clearly showed erratic behavior. There's one piece of code i suspect in particular - could you try the patch below ontop of -U8? (i have compile- and boot- tested it)

Ingo

kernel/sched.c renamed from kernel/sched.c.orig +6 -5
@@ -2764,6 +2764,8 @@ need_resched:
 		else
 			deactivate_task(prev, rq);
 	}
+	if (preempt_count() & PREEMPT_ACTIVE)
+		sub_preempt_count(PREEMPT_ACTIVE);
 	if (unlikely(prev->flags & PF_DEAD)) {
 		BUG_ON(prev->state != TASK_RUNNING);
 		prev->state = __TASK_DEAD;
@@ -2940,6 +2942,7 @@ asmlinkage void __sched preempt_schedule
 		return;
 
 need_resched:
+	local_irq_disable();
 	add_preempt_count(PREEMPT_ACTIVE);
 	/*
 	 * We keep the big kernel semaphore locked, but we
@@ -2950,11 +2953,10 @@ need_resched:
 	saved_lock_depth = task->lock_depth;
 	task->lock_depth = -1;
 #endif
-	schedule();
+	__schedule();
 #ifdef CONFIG_PREEMPT_BKL
 	task->lock_depth = saved_lock_depth;
 #endif
-	sub_preempt_count(PREEMPT_ACTIVE);
 
 	/* we could miss a preemption opportunity between schedule and now */
 	barrier();
@@ -3002,7 +3004,6 @@ need_resched:
 #ifdef CONFIG_PREEMPT_BKL
 	task->lock_depth = saved_lock_depth;
 #endif
-	sub_preempt_count(PREEMPT_ACTIVE);
 
 	/* we could miss a preemption opportunity between schedule and now */
 	barrier();
@@ -3842,9 +3843,9 @@ static inline void __cond_resched(void)
 	if (preempt_count() & PREEMPT_ACTIVE)
 		return;
 	do {
+		local_irq_disable();
 		add_preempt_count(PREEMPT_ACTIVE);
-		schedule();
-		sub_preempt_count(PREEMPT_ACTIVE);
+		__schedule();
 	} while (need_resched());
 }
 
#244 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · On Wed, 20 Oct 2004 14:55:00 +0200 Ingo Molnar <[email protected]> wrote:

i dont think it's caused by trace_enabled - the trace you sent last time clearly showed erratic behavior. There's one piece of code i suspect in particular - could you try the patch below ontop of -U8? (i have compile- and boot- tested it)

mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
patching file kernel/sched.c
Hunk #5 succeeded at 3843 with fuzz 1.

building anyways, reporting later..

flo

#245 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 10 lines · Florian Schmidt
Quoted 4 lines

i dont think it's caused by trace_enabled - the trace you sent last time clearly showed erratic behavior. There's one piece of code i suspect in particular - could you try the patch below ontop of -U8? (i have compile- and boot- tested it)

mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
patching file kernel/sched.c
Hunk #5 succeeded at 3843 with fuzz 1.

building anyways, reporting later..

never worry about a fuzz when applying patches - as long as you dont get a reject it should be ok.

Ingo

#246 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Florian Schmidt
Quoted 8 lines · On Wed, 20 Oct 2004 15:25:07 +0200 Florian Schmidt <[email protected]> wrote:
Quoted 4 lines · On Wed, 20 Oct 2004 14:55:00 +0200 Ingo Molnar <[email protected]> wrote:

i dont think it's caused by trace_enabled - the trace you sent last time clearly showed erratic behavior. There's one piece of code i suspect in particular - could you try the patch below ontop of -U8? (i have compile- and boot- tested it)

Quoted 5 lines
mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
patching file kernel/sched.c
Hunk #5 succeeded at 3843 with fuzz 1.

building anyways, reporting later..

Hi,

it seems that the pauses went away with that patch. The system is showing a different weird behaviour now. On last bootup the machine slowly died away (first my email program froze upon checking for mail, then starting top would just hang the respective xterm. ps still ran and procuced output [i didn't capture it though, doh], other stuff would hang, too. upon ctrl-alt-bkspc to kill the x server, it all locked up.. i have no serial console or other machine to test if it was still up in any way.

And on this bootup the pauses are still gone, but as soon as i echo'ed 1 into trace_enabled the mouse started to become very skippy (update freq at about 3hz). Keyboard is fine though.. putting trace_enabled back to 0 doesn't fix it. I suppose it's just a matter of time until the next lockup. We'll see though..

Syslog only sees critical section timing reports, no BUG's afaics.

flo

#247 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines · Florian Schmidt

Hi,

it seems that the pauses went away with that patch. [...]

great! I've uploaded -U8.1 with this fix included:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8.1

Quoted 7 lines

And on this bootup the pauses are still gone, but as soon as i echo'ed 1 into trace_enabled the mouse started to become very skippy (update freq at about 3hz). Keyboard is fine though.. putting trace_enabled back to 0 doesn't fix it. I suppose it's just a matter of time until the next lockup. We'll see though..

Syslog only sees critical section timing reports, no BUG's afaics.

note that the keyboard and USB interrupts are SCHED_OTHER by default, so they could be delayed quite long depending on the workload. To avoid that i'd suggest to:

        chrt --fifo --pid 30 `pidof 'IRQ 1'`
        chrt --fifo --pid 30 `pidof 'IRQ 12'`

(do this for every IRQ you have for input devices.) This puts them below jackd's priority (which is FIFO 50 iirc) but above all SCHED_OTHER tasks. The soundcard IRQ i guess you have chrt-ed already?

or did you have them on SCHED_FIFO already?

Ingo

#248 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · On Wed, 20 Oct 2004 16:18:22 +0200 Ingo Molnar <[email protected]> wrote:

note that the keyboard and USB interrupts are SCHED_OTHER by default, so they could be delayed quite long depending on the workload. To avoid that i'd suggest to:

Quoted 8 lines
        chrt --fifo --pid 30 `pidof 'IRQ 1'`
        chrt --fifo --pid 30 `pidof 'IRQ 12'`

(do this for every IRQ you have for input devices.) This puts them below jackd's priority (which is FIFO 50 iirc) but above all SCHED_OTHER tasks. The soundcard IRQ i guess you have chrt-ed already?

or did you have them on SCHED_FIFO already?

setting them to SCHED_FIFO even with a prio of 99 won't help. will try rebooting to see if it's reproducable

flo

#249 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · On Wed, 20 Oct 2004 16:53:26 +0200 Florian Schmidt <[email protected]> wrote:

setting them to SCHED_FIFO even with a prio of 99 won't help. will try rebooting to see if it's reproducable

flo

ok, it seems it was coincidence that the mouse skipping started at the time of my echo 1 > trace_enabled.. This time it just started sometime after boot. The scheduler class of the different irq's seems to have no influence [i experimented with SCHED_FIFO and SCHED_OTHER for irq 1, 8, 12 and 3 and 10 [the latter two are my soundcards irq's].

~$ cat /proc/interrupts
CPU0

  0:     480317          XT-PIC  timer  0/80317
  1:       1731          XT-PIC  i8042  0/1731
  2:          0          XT-PIC  cascade  0/0
  3:      10828          XT-PIC  CS46XX  0/10828
  5:        390          XT-PIC  eth0  0/390
  8:          4          XT-PIC  rtc  0/4
 10:     251556          XT-PIC  SiS SI7012  0/51556
 12:      16605          XT-PIC  i8042  0/16604
 14:       1151          XT-PIC  ide0  0/1151
 15:      26537          XT-PIC  ide1  0/26537
NMI:          0 
ERR:          0

Btw: i just experienced two pauses again, so the patch didn't really fix it :( hrmm..

I get the feeling that something indeterministic is going on. Still no BUG's in either dmesg output nor in the syslog.

flo

#250 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 2 lines · Ingo Molnar

note that the keyboard and USB interrupts are SCHED_OTHER by default, so they could be delayed quite long depending on the workload.

Why is this the default behavior? It seems like you would want all IRQ
threads to be SCHED_FIFO by default. Otherwise it seems like the
scheduler could decide to run a normal userspace process (like, say, X) while an IRQ thread is runnable.

Is it really a good idea for IRQ threads to be subject to the whims of the scheduler?

Also, on modern machines, this would effectively make all IRQ threads SCHED_OTHER because the USB port shares an interrupt with everything:

  0:   36676353          XT-PIC  timer  0/76353
  1:       8759          XT-PIC  i8042  5/8759
  2:          0          XT-PIC  cascade  0/0
  8:          4          XT-PIC  rtc  0/4
 10:          0          XT-PIC  uhci_hcd  0/0
 11:     210713          XT-PIC  uhci_hcd, eth0  0/10713
 12:          0          XT-PIC  uhci_hcd  0/0
 15:      79277          XT-PIC  ide1  0/79276
NMI:          0
ERR:          0

Lee

#251 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: irtty_sir sir_dev irda crc_ccitt usbcore lp ipv6 dm_mod it87 i2c_isa i2c
CPU:    0
EIP:    0060:[<c01dfa5b>]    Not tainted VLI
EFLAGS: 00010287   (2.6.9-rc4-mm1-RT-U8) 

EIP is at up_write+0x1eb/0x200
eax: de848000 ebx: df3a255c ecx: 0000001f edx: c14e3260
esi: df3a24c8 edi: de848000 ebp: de849f7c esp: de849f5c
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process kIrDAd (pid: 1295, threadinfo=de848000 task=df3d6110)

Stack: e09119bb de849f74 c0111590 df3a2400 0000001f df3a255c e0915000 de848000 
       de849f94 e09119bb df3a2400 00000282 de849fc4 00000000 de849fec e0911ae2 
       e09129c2 de849fb8 00000000 df3d6110 c01148d0 00000000 00000000 de84ff08 
Call Trace:
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (4)
 [<c0111590>] mcount+0x14/0x18 (8)
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (28)
 [<e0911ae2>] irda_thread+0xb2/0xf0 [sir_dev] (24)
 [<c01148d0>] default_wake_function+0x0/0x20 (20)
 [<c010612a>] ret_from_fork+0x6/0x14 (16)
 [<c01148d0>] default_wake_function+0x0/0x20 (16)
 [<e0911a30>] irda_thread+0x0/0xf0 [sir_dev] (24)
 [<c0104319>] kernel_thread_helper+0x5/0xc (12)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3f/0x1a0 / (do_invalid_op+0x106/0x110) .. entry 2: print_traces+0x1d/0x80 / (show_stack+0x83/0xa0)

Code: ff e9 44 ff ff ff 0f 0b a5 00 13 ce 2e c0 eb b6 0f 0b a4 00 13 ce 2e c0 eb a5 c7 04 2
 (events/0/3/CPU#0): new 785 us maximum-latency critical section.
 => started at timestamp 193385865: <kernel_fpu_begin+0x21/0x60>
 =>   ended at timestamp 193386650: <_mmx_memcpy+0x131/0x180>
 [<c012f070>] sub_preempt_count+0x60/0x90 (4)
 [<c012ed5e>] check_preempt_timing+0x15e/0x270 (8)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (8)
 [<c012f070>] sub_preempt_count+0x60/0x90 (64)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (8)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (16)
 [<c01ee1d0>] vgacon_save_screen+0x80/0x90 (28)
 [<c021ba89>] redraw_screen+0x199/0x270 (28)
 [<c012e4ed>] __mcount+0x1d/0x20 (12)
 [<c0216d61>] complete_change_console+0x11/0x100 (4)
 [<c021ec86>] console_callback+0xe6/0xf0 (4)
 [<c0216d89>] complete_change_console+0x39/0x100 (28)
 [<c021ec86>] console_callback+0xe6/0xf0 (28)
 [<c0128e63>] worker_thread+0x1d3/0x2a0 (20)
 [<c021eba0>] console_callback+0x0/0xf0 (28)
 [<c01148d0>] default_wake_function+0x0/0x20 (28)
 [<c01148d0>] default_wake_function+0x0/0x20 (32)
 [<c0111590>] mcount+0x14/0x18 (12)
 [<c012d26a>] kthread+0xaa/0xb0 (28)
 [<c0128c90>] worker_thread+0x0/0x2a0 (20)
 [<c012d1c0>] kthread+0x0/0xb0 (12)
 [<c0104319>] kernel_thread_helper+0x5/0xc (16)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180) .. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

=> dump-end timestamp 193387119

#252 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Lorenzo Allegrucci

Process kIrDAd (pid: 1295, threadinfo=de848000 task=df3d6110)

Call Trace:
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (4)
 [<c0111590>] mcount+0x14/0x18 (8)
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (28)
 [<e0911ae2>] irda_thread+0xb2/0xf0 [sir_dev] (24)

ok - IRDA too needs fixing. Disable CONFIG_IRDA for the time being.

Ingo

#253 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

used i386/defconfig

1. at boot
[...skip...]
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: hda1 hda2 hda3 hda4 < hda5 >

BUG: semaphore recursion deadlock detected!
.. current task khpsbpkt/723 is already holding c04610c0.
00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020
       00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 
c03b3efa
       dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 
c01fd364
Call Trace:
 [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
 [<c01051c9>] show_trace+0x4e/0xcc (12)
 [<c01052c9>] show_stack+0x82/0x97 (36)
 [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
 [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)
[...skip...]

2.
if execute
``for i in seq 1 9999; do nohup bash >/dev/null 2>&1 & done'', then you'll get something like:
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open [...skip...]
Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)

[...skip...]

I'v tested it against linux-2.6.9-rc4-mm1 => all was ok

See full logs in attachments

-bash

Linux version 2.6.9-rc4-mm1-RT-U8 ([email protected]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #3 SMP Wed Oct 20 16:26:38 MSD 2004 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff30000 (usable)
BIOS-e820: 000000001ff30000 - 000000001ff40000 (ACPI data)
BIOS-e820: 000000001ff40000 - 000000001fff0000 (ACPI NVS)
BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000ff780
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: ASUSTeK Product ID: P4P800SE APIC at: 0xFEE00000
I/O APIC #13 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda2 console=ttyS0,57600
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2798.899 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 512196k/523456k available (2687k kernel code, 10700k reserved, 1089k data, 184k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
per-CPU timeslice cutoff: 2926.33 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 2000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Total of 2 processors activated (11108.35 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
ksoftirqd started up.
Brought up 2 CPUs
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/24d0] at 0000:00:1f.0
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P1) -> 19
PCI->APIC IRQ transform: (B0,I29,P2) -> 18
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P3) -> 23
PCI->APIC IRQ transform: (B0,I31,P0) -> 18
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI->APIC IRQ transform: (B2,I5,P0) -> 22
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1098277485.061:0): initialized
Installing knfsd (copyright (C) 1996 [email protected]).
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 865 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xf8000000
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport0: PC-style at 0x378 [PCSPP(,...)]
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
PrefPort:A RlmtMode:Check Link State
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio

hda: SAMSUNG SP0411N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: hda1 hda2 hda3 hda4 < hda5 >

BUG: semaphore recursion deadlock detected!
.. current task khpsbpkt/723 is already holding c04610c0.
00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020 
       00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 c03b3efa 
       dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 c01fd364 
Call Trace:
 [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
 [<c01051c9>] show_trace+0x4e/0xcc (12)
 [<c01052c9>] show_stack+0x82/0x97 (36)
 [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
 [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:498!
invalid operand: 0000 [#1]
PREEMPT SMP 
Modules linked in:
CPU:    1
EIP:    0060:[<c039e2b7>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U8) 

EIP is at down_write_interruptible+0xfd/0x202
eax: 00000001 ebx: c04610c0 ecx: dfdc8000 edx: 00000001
esi: dfdc78f0 edi: c04610c4 ebp: dfdc9fc0 esp: dfdc9fb4
ds: 007b es: 007b ss: 0068 preempt: 00000003
Process khpsbpkt (pid: 723, threadinfo=dfdc8000 task=dfdc78f0)

Stack: c04610c0 000001d6 c04610c0 c04610cc c04610cc dfdc78f0 00000002 dfdc8000 
       00000000 00000000 00000000 c029dd80 c03cd95b ffffffff c029dd55 c01024d1 
       00000000 00000000 00000000 
Call Trace:
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 4: print_traces+0x17/0x50 / (0x0)

Code: 44 24 0c 89 68 04 89 2a 89 54 24 10 89 1c 24 e8 eb ef e5 ff 85 c0 74 1b a1 2c e0 41 c0 85 c0 74 12 c7 05 2c e0 41 c0 00 00 00 00 <0f> 0b f2 01 cf 73 3c c0 89 9e 1c 06 00 00 9c 58 c1 e8 09 83 f0 
 <3>BUG: scheduling while atomic: khpsbpkt/0x04000002/723

ieee1394: raw1394: /dev/raw1394 device initialized
ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xfebffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.2
uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 caller is cond_resched+0x5e/0x7f

 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (56)
 [<c0105aff>] do_invalid_op+0x0/0xf7<7>PCI: Setting latency timer of device 0000:00:1d.0 to 64

uhci_hcd 0000:00:1d.0: irq 16, io base 0xef00
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
(16)
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0xef20
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
[<c039daa9>] cond_resched+0x5e/0x7f<7>PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0xef40
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.3: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
(8)
[<c039dee7>]<7>PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: irq 16, io base 0xef80
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0

 down_read+0x33/0x18a (16)
 [<c0110963>] smp_apic_timer_interrupt+0x6d/0xe2 (12)
 [<c039e92b>] _spin_unlock_irq+0x18/0x2e (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c011bab5>] profile_task_exit+0x15/0x3e (4)
 [<c011dab4>] do_exit+0x18/0x3b1 (20)
 [<c011007b>] flush_tlb_all+0x26/0x65 (12)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86<6>input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 04000003
Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC). . 3-level deep critical section nesting:
PCI: Setting latency timer of device 0000:00:1f.5 to 64
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

note: khpsbpkt[723] exited with preempt_count 2

BUG: scheduling while atomic: khpsbpkt/0x04000002/723
caller is cond_resched+0x5e/0x7f
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c01202d4>] __do_softirq+0x36/0x88 (36)
 [<c039daa9>] cond_resched+0x5e/0x7f (44)
 [<c039e068>] down_write+0x2a/0x17c (16)
 [<c011d22e>] exit_notify+0x28/0x896 (40)
 [<c011b552>] vprintk+0x11e/0x15b (24)
 [<c011dd81>] do_exit+0x2e5/0x3b1 (44)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: khpsbpkt/0x00000002/723
caller is do_exit+0x2ee/0x3b1
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (8)
 [<c011d486>] exit_notify+0x280/0x896 (12)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7<6>intel8x0_measure_ac97_clock: measured 50107 usecs

intel8x0: clocking to 48000
ALSA device list:
#0: Intel ICH5 with AD1985 at 0xfebff800, irq 17
oprofile: using NMI interrupt.
(28)

 [<c011b552>] vprintk+0x11e/0x15b<6>NET: Registered protocol family 2
 (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

------------[ cut here ]------------
kernel BUG at kernel/sched.c:2768!
invalid operand: 0000 [#2]
PREEMPT SMP 
Modules linked in:
CPU:    1
EIP:    0060:[<c039d094>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U8) 

EIP is at __sched_text_start+0x64c/0x730
eax: 00000001 ebx: dfdc8000 ecx: dfdc78f0 edx: c14340bc
esi: dfdc78f0 edi: dfdc7a60 ebp: dfdc9e58 esp: dfdc9e08
ds: 007b es: 007b ss: 0068 preempt: 00000005
Process khpsbpkt (pid: 723, threadinfo=dfdc8000 task=dfdc78f0)

Stack: dfdc78f0 c1433820 00000002 000002d3 c011d486 c04a6d00 00000011 00000286 
       00000033 dfdc7950 dfdc7994 c1433820 0f5d9fc7 77b2f71c 00000001 dfdc78f0 
       dfdc7a5c c165c780 dfdc78f0 dfdc7db8 dfdc9fc0 c011dd8a dfdc78f0 00000000 
Call Trace:
 [<c011d486>] exit_notify+0x280/0x896 (20)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 00000006
. 6-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: __sched_text_start+0x36/0x730 / (0x0)
.. entry 4: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 5: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 6: print_traces+0x17/0x50 / (0x0)

Code: 8b 45 dc 8b 50 08 eb c7 8b 01 85 c0 75 1d 8b 7d ec c7 07 20 00 00 00 89 3c 24 8b 45 dc 89 44 24 04 e8 5b 7b d7 ff e9 fe fa ff ff <0f> 0b d0 0a 82 5c 3b c0 eb d9 8b 7d ec c7 07 00 00 00 00 e9 d9 
 <3>BUG: scheduling while atomic: khpsbpkt/0x04000004/723
caller is cond_resched+0x5e/0x7f
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c0116664>] scheduler_tick+0x183/0x517 (28)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c039dee7>] down_read+0x33/0x18a (16)
 [<c0110963>] smp_apic_timer_interrupt+0x6d/0xe2 (12)
 [<c039e92b>] _spin_unlock_irq+0x18/0x2e (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c011bab5>] profile_task_exit+0x15/0x3e (4)
 [<c011dab4>] do_exit+0x18/0x3b1 (20)
 [<c011007b>] flush_tlb_all+0x26/0x65 (12)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039d094>] __sched_text_start+0x64c/0x730 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039d094>] __sched_text_start+0x64c/0x730 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (84)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c011007b>] flush_tlb_all+0x26/0x65 (40)
 [<c039d094>] __sched_text_start+0x64c/0x730 (12)
 [<c011d486>] exit_notify+0x280/0x896 (28)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)

preempt count: 04000005
. 5-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: __sched_text_start+0x36/0x730 / (0x0)
.. entry 4: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 5: print_traces+0x17/0x50 / (0x0)

Linux version 2.6.9-rc4-mm1-RT-U8 ([email protected]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #11 SMP Wed Oct 20 18:49:11 MSD 2004 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff30000 (usable)
BIOS-e820: 000000001ff30000 - 000000001ff40000 (ACPI data)
BIOS-e820: 000000001ff40000 - 000000001fff0000 (ACPI NVS)
BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000ff780
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda2 console=ttyS0,57600
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2798.919 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 512132k/523456k available (2689k kernel code, 10764k reserved, 1111k data, 192k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
per-CPU timeslice cutoff: 2926.33 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Total of 2 processors activated (11108.35 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
ksoftirqd started up.
Brought up 2 CPUs
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1098284016.319:0): initialized
Installing knfsd (copyright (C) 1996 [email protected]).
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU1] (supports C1)
ACPI: Processor [CPU2] (supports C1)
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 865 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xf8000000
ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport0: PC-style at 0x378 [PCSPP(,...)]
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Floppy Controller [FDC] at I/O 0x3f0-0x3f5, 0x3f7 irq 6 dma channel 2
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio

hda: SAMSUNG SP0411N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: hda1 hda2 hda3 hda4 < hda5 >
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xfebffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
uhci_hcd 0000:00:1d.0: irq 16, io base 0xef00
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
uhci_hcd 0000:00:1d.1: irq 19, io base 0xef20
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
uhci_hcd 0000:00:1d.2: irq 18, io base 0xef40
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.3: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
uhci_hcd 0000:00:1d.3: irq 16, io base 0xef80
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC).
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17
AC'97 0 analog subsections not ready
intel8x0_measure_ac97_clock: measured 49987 usecs
intel8x0: clocking to 48000
ALSA device list:
#0: Intel ICH5 with AD1985 at 0xfebff800, irq 17
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP: routing cache hash table of 128 buckets, 21Kbytes
TCP: Hash tables configured (established 1024 bind 1560)
ip_conntrack version 2.1 (4089 buckets, 32712 max) - 308 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <[email protected]>. http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
ACPI: (supports S0 S1 S3 S4 S5)
ACPI wakeup devices:
P0P4 MC97 USB1 USB2 USB3 USB4 EUSB PS2K PS2M ILAN
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 192k freed
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open
[...skip...]
Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0143645>] buffered_rmqueue+0x89/0x1f4 (28)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (48)
 [<c039e226>] cond_resched+0x20/0x7f (32)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f019>] _spin_unlock+0x12/0x2d (16)
 [<c039f019>] _spin_unlock+0x12/0x2d (16)
 [<c0147f5e>] cache_grow+0x147/0x16f (8)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (28)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20

 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)

preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

Warning: trace overflow for c0414d40 (32), increase RWSEM_MAX_OWNERS ... disabling semaphore tracing and deadlock detection.

BUG: sleeping function called from invalid context bash(24154) at drivers/block/ll_rw_blk.c:1283
in_atomic():1 [00000001], irqs_disabled():1
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c026d24f>] generic_unplug_device+0x1f/0x50 (36)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling with irqs disabled: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d99f>] schedule+0x6c/0xb9 (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (24)
 [<c026d254>] generic_unplug_device+0x24/0x50 (16)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (12)
 [<c0106116>] dump_stack+0x1c/0x20 (56)
 [<c039d99f>] schedule+0x6c/0xb9 (16)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (24)
 [<c026d254>] generic_unplug_device+0x24/0x50 (16)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039e69d>] down_read+0x2e/0x18a (36)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c039e6a2>] down_read+0x33/0x18a (16)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039e69d>] down_read+0x2e/0x18a (36)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c039e6a2>] down_read+0x33/0x18a (16)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (24)
 [<c039e69d>] down_read+0x2e/0x18a (12)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at kernel/mutex.c:25
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c0133970>] _mutex_lock+0x1f/0x3b (36)
 [<c014e847>] do_swap_page+0x92/0x2da (16)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c0133975>] _mutex_lock+0x24/0x3b (16)
 [<c014e847>] do_swap_page+0x92/0x2da (16)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)

preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is do_exit+0x2ee/0x3b1
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c01219a6>] do_exit+0x2ee/0x3b1 (8)
 [<c01210a2>] exit_notify+0x280/0x896 (48)
 [<c01219a6>] do_exit+0x2ee/0x3b1 (68)
 [<c0121b82>] do_group_exit+0x91/0xb5 (36)
 [<c012acfd>] get_signal_to_deliver+0x1bf/0x396 (24)
 [<c01050ea>] do_signal+0xe3/0x11b (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c010517a>] do_notify_resume+0x58/0x5a (28)
 [<c01052f7>] work_notifysig+0x13/0x18 (12)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
Stopping atd: [ OK ]
Stopping keytable: [ OK ]
Stopping cups: [ OK ]
Shutting down xfs: [ OK ]
Shutting down console mouse services: [ OK ]
Stopping sshd:[ OK ]
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
Stopping xinetd: [ OK ]
Stopping crond: [ OK ]
Saving random seed: [ OK ]
Stopping NFS statd:

#254 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 64 lines · Alexander Batyrshin
Quoted 4 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

2.
if execute
``for i in seq 1 9999; do nohup bash >/dev/null 2>&1 & done'', then you'll get something like:
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open [...skip...]
Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
eggcups: page allocation failure. order:1, mode:0x20

Quoted 4 lines
  [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
  [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
  [<c014719c>] kmem_getpages+0x25/0xe0 (8)

[...skip...]

I got something like this too, just now. Not doing anything special(tty7 holds xdm).

Warning: dev (pts7) tty->count(4) != #fd's(3) in tty_open
Warning: dev (pts7) tty->count(4) != #fd's(3) in release_dev

#255 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Alexander Batyrshin
Quoted 29 lines · Alexander Batyrshin
Quoted 4 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

used i386/defconfig

1. at boot
[...skip...]
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: hda1 hda2 hda3 hda4 < hda5 >

BUG: semaphore recursion deadlock detected!
.. current task khpsbpkt/723 is already holding c04610c0.
00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020
        00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 
c03b3efa
        dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 
c01fd364
Call Trace:
  [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
  [<c01051c9>] show_trace+0x4e/0xcc (12)
  [<c01052c9>] show_stack+0x82/0x97 (36)
  [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
  [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
  [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
  [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
  [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
Quoted 6 lines

preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)
[...skip...]

This looks related to IEEE1394 . It has a deadlock in it. Try turning it off..

Daniel

#256 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Alexander Batyrshin
Quoted 4 lines · Alexander Batyrshin

used i386/defconfig

BUG: semaphore recursion deadlock detected!

.. current task khpsbpkt/723 is already holding c04610c0.

ok, this should be fixed in -U9.2.

Quoted 9 lines

2.
if execute
``for i in seq 1 9999; do nohup bash >/dev/null 2>&1 & done'', then you'll get something like:
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open

I'v tested it against linux-2.6.9-rc4-mm1 => all was ok

i have trouble reproducing this myself. Can you still trigger it under -U9.2? If yes then could you check whether this still happens with a the same .config but with CONFIG_SMP turned off? This smells like a locking bug/breakage in the tty layer that we dont detect. You have all the relevant debug options turned on, correct? (DEBUG_PREEMPT and RWSEM_DEADLOCK_DETECT)

Ingo

#257 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Alexander Batyrshin
Quoted 7 lines · Alexander Batyrshin

2.
if execute
``for i in seq 1 9999; do nohup bash >/dev/null 2>&1 & done'', then you'll get something like:
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open

btw., where did you run the test - over ssh or in an xterm?

Ingo

#258 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar

Hi,
I finally got around to get my labtop up running with this. It works -
nearly that is - X even started up!

When I start the network I get the trace below. And my network runs awfully slowly. Could seem like the interrupt doesn't work correctly....

Regards,
Esben

Oct 20 21:45:53 localhost kernel: e100: Intel(R) PRO/100 Network Driver,
3.1.4-k
2-NAPI
Oct 20 21:45:53 localhost kernel: e100: Copyright(c) 1999-2004 Intel
Corporation
Oct 20 21:45:53 localhost kernel: ACPI: PCI interrupt 0000:00:09.0[A] ->
GSI 11 
(level, low) -> IRQ 11
Oct 20 21:45:53 localhost kernel: e100: eth0: e100_probe: addr 0x41280000,
irq 1
1, MAC addr 00:D0:59:2D:91:84
Oct 20 21:45:53 localhost kernel: ip/1988: BUG in enable_irq at
/misc/frodo_opt3
/simlo/Linux-RT/linux-2.6.9-rc4-mm1-rt-u8.1/kernel/irq/manage.c:111
Oct 20 21:45:53 localhost kernel:  [<c013614e>] enable_irq+0xee/0x100 (12)
Oct 20 21:45:53 localhost kernel:  [<d089741e>] e100_up+0x10e/0x200 [e100]
(48)
Oct 20 21:45:54 localhost kernel:  [<d08987c0>] e100_open+0x30/0x80 [e100]
(48)
Oct 20 21:45:54 localhost kernel:  [<c010fe00>] mcount+0x14/0x18 (12)
Oct 20 21:45:54 localhost kernel:  [<c02ea108>] dev_open+0x88/0xa0 (20)
Oct 20 21:45:54 localhost kernel:  [<c02eb82d>]
dev_change_flags+0x5d/0x140 (28)
Oct 20 21:45:54 localhost kernel:  [<c02e976e>] __dev_get_by_name+0xe/0xd0
(8)
Oct 20 21:45:54 localhost kernel:  [<c03293b7>] devinet_ioctl+0x277/0x6e0
(28)
Oct 20 21:45:54 localhost kernel:  [<c032b834>] inet_ioctl+0x64/0xb0 (108)
Oct 20 21:45:54 localhost kernel:  [<c02e0ae8>] sock_ioctl+0xc8/0x250 (28)
Oct 20 21:45:54 localhost kernel:  [<c016a319>] sys_ioctl+0xc9/0x230 (32)
Oct 20 21:45:54 localhost kernel:  [<c01046fd>]
sysenter_past_esp+0x52/0x71 (44)
Oct 20 21:45:54 localhost kernel: preempt count: 00000002
Oct 20 21:45:54 localhost kernel: . 2-level deep critical section nesting:
Oct 20 21:45:54 localhost kernel: .. entry 1: enable_irq+0x2e/0x100 /
(e100_up+0
x10e/0x200 [e100])
Oct 20 21:45:54 localhost kernel: .. entry 2: print_traces+0x1d/0x60 /
(dump_sta
ck+0x23/0x30)
Oct 20 21:45:54 localhost kernel: 
Oct 20 21:45:54 localhost kernel: e100: eth0: e100_watchdog: link up, 

10Mbps, ha

Quoted 60 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

this too is a fixes-only release. It includes the many semaphore-abuse and sleep_on() fixes/improvements from Thomas Gleixner, and it also includes a couple of semaphore related fixes.

I believe the semaphore fixes should resolve a number of the deadlocks reported for -U7.

In particular it seems the only sane and reliable way to convert RCU locking was to allow the following semantics for rwsems: allow reads to nest, and allow self-read-recursion of a self-write-held semaphore. My current implementation for this allows semaphore unfairness, but that can be fixed later on. Most importantly, the RCU to RT-locking conversions are much more automatic now and map nicely to what the code is doing upstream. Most of the time they involve a conversion of a spinlock or semaphore into a rwlock or rwsem. The old code maps to new code almost automatically, the only manual work needed was to associate the rcu_read_lock() with the writers-lock that it excludes against, which is a pretty clear (but not automatic, and hence not automatable) decision. This way i could convert some more networking code, and simplify the older changes and hopefully get rid of some deadlocks. The locking API is still not in its final form, but it's getting closer.

Changes since -U7:

- deadlock fix: sysfs/driver-base semaphore fixes from Thomas Gleixner

- deadlock fix: scsi semaphore fixes from Thomas Gleixner

- NFS sleep_on() fixes from Thomas Gleixner

- rawmidid.c sleep_on() fix from Thomas Gleixner

- [ i've added more wait_for_completion_*() primitives, to ease conversion of other semaphore-(ab-)using code. ]

- make rwsems self-recursive

- RCU lock conversion: convert rtnl_sem RCU use.

- netfilter deadlock fix - clean up RCU locking.

to create a -U8 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2

+ http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
+ http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
+ http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#259 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

this too is a fixes-only release.

A bit late, but a short report. I managed to boot into U8.1 (Athlon64 up machine). But only if I turn off kudzu (the hardware discovery program in FC2). If I leave it on, I get tons of kernel error or warning messages on the console, they scroll too fast for me to read, once that starts the machine is pretty much stuck - the messages keep scrolling but that's about it. I have not managed to capture the output to see what they say...

If I boot without kudzu I can use sound, but I have not done yet any latency testing.

-- Fernando

#260 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Ingo Molnar
Quoted 5 lines · Ingo Molnar

i have released the -U8 Real-Time Preemption patch:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Hi,

I'm posting this time about to report my current status of my two
boxes, regarding the realtime-preempt-2.6.9-rc4-mm1-U8 patch. So it seems that now the positions have been somewhat reversed. Respective config.gz are attached.

a) Desktop P4 [email protected] SMP/HT (SuSE 9.1 Pro)
config-2.6.9-rc4-mm1-RT-U8.0smp.gz

This is apparently but surprinsingly OK, as everything seems to work
flawlessly, besides some quirks on the onboard NIC (sk98lin) that only shows up initially but stabilizes later on. Indeed, U8 is the first SMP+PREEMPT_REALTIME encarnation that runs at all and is fairly workable on this machine. This is a relief.

b) Laptop P4 2.533Ghz UP (Mandrake 10.1c)
config-2.6.9-rc4-mm1-RT-U8.1.gz

This box was known to work without major issues until U4. With U8 it's
a real pain. Once trivial operations turns out fatal now. Running jackd -R, which has been a flagship before, now freezes the whole system in no time. (I'll take some netconsole capture sessions later)

One of the signs that there's real trouble in here can be seen on the
following complete dmesg output (which was even a miracle to be captured at all). This shows the complete bootstrap and init sequences and at the end one fatal crash while plugging an USB flash memory stick (usb-storage). This has been already reported earlier yesterday, but I just want to make it here, as the evidence-at-hand.

After this precise occurence, the system becomes very flaky, unreliable
and often ends up freezing to death.

Hope this helps (me)

Bye now.
--
Linux version 2.6.9-rc4-mm1-RT-U8.1 (root@lambda) (gcc version 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)) #1 Thu Oct 21 09:08:18 WEST 2004 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001f770000 (usable)
BIOS-e820: 000000001f770000 - 000000001f77f000 (ACPI data)
BIOS-e820: 000000001f77f000 - 000000001f780000 (ACPI NVS)
BIOS-e820: 000000001f780000 - 000000001f800000 (reserved)
BIOS-e820: 000000002f780000 - 000000002f800000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
503MB LOWMEM available.
On node 0 totalpages: 128880
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 124784 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 PTLTD ) @ 0x000f6c70
ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x1f7783fd
ACPI: FADT (v001 ATI Salmon 0x06040000 ATI 0x000f4240) @ 0x1f77ef64
ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) @ 0x1f77efd8
ACPI: DSDT (v001 ATI MS2_1535 0x06040000 MSFT 0x0100000e) @ 0x00000000
Built 1 zonelists
No local APIC present or hardware disabled
Initializing CPU#0
Kernel command line: BOOT_IMAGE=linux-RT-U8.1 ro root=305 devfs=nomount acpi=on
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2525.698 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 507728k/515520k available (1791k kernel code, 7300k reserved, 591k data, 152k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 4931.58 BogoMIPS (lpj=2465792) Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080
CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: IRQ9 SCI: Edge set to Level Trigger.
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd88b, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK0] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 7 *10)
ACPI: PCI Interrupt Link [LNK2] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 7 *10)
ACPI: PCI Interrupt Link [LNK5] (IRQs 7 *11)
ACPI: PCI Interrupt Link [LNK6] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK7] (IRQs *5)
ACPI: PCI Interrupt Link [LNK8] (IRQs 7 *10)
ACPI: Embedded Controller [EC0] (gpe 24)
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
Simple Boot Flag at 0x37 set to 0x1
devfs: 2004-01-31 Richard Gooch ([email protected])
devfs: boot_options: 0x0
Activating ISA DMA hang workarounds.
Real Time Clock Driver v1.12
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
PCI: Enabling device 0000:00:08.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNK6] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 10 (level, low) -> IRQ 10 ttyS0 at I/O 0x1428 (irq = 10) is a 8250
ttyS2 at I/O 0x1440 (irq = 10) is a 8250
ttyS3 at I/O 0x1450 (irq = 10) is a 8250
ttyS4 at I/O 0x1460 (irq = 10) is a 8250
ttyS5 at I/O 0x1470 (irq = 10) is a 8250
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Floppy Controller [FDC] at I/O 0x3f0-0x3f5, 0x3f7 irq 6 dma channel 2
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:10.0
ACPI: PCI interrupt 0000:00:10.0[A]: no GSI
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x2008-0x200f, BIOS settings: hdc:pio, hdd:pio

Probing IDE interface ide0...
hda: IC25N040ATCS04-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4240N, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 128KiB
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 >
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
Synaptics Touchpad, model: 1
Firmware: 5.8
Sensor: 35
new absolute packet format
Touchpad has extended capability bits
-> multifinger detection
-> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 128 buckets, 20Kbytes
TCP: Hash tables configured (established 1024 bind 1638)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 152k freed
kjournald starting. Commit interval 5 seconds
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports C1 C2)
ACPI: Thermal Zone [THRM] (52 C)
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNK8] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 10 (level, low) -> IRQ 10 ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: irq 10, pci mem 0xd4000000
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:0f.0[A] -> GSI 10 (level, low) -> IRQ 10 ohci_hcd 0000:00:0f.0: OHCI Host Controller
ohci_hcd 0000:00:0f.0: irq 10, pci mem 0xd4009000
ohci_hcd 0000:00:0f.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
EXT3 FS on hda5, internal journal
Adding 506008k swap on /dev/hda6. Priority:-1 extents:1 kjournald starting. Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
subfs 0.9
loop: loaded (max 8 devices)
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker <[email protected]>
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 10 (level, low) -> IRQ 10 natsemi eth0: NatSemi DP8381[56] at 0xd400a000 (0000:00:12.0), 00:0b:cd:85:0f:54, IRQ 10, port TP.
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
PCI: Enabling device 0000:00:0a.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 11 (level, low) -> IRQ 11
Yenta: CardBus bridge found at 0000:00:0a.0 [103c:0850]
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000007
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
prism2_cs: Ignoring new-style parameters in presence of obsolete ones
prism2cs_init: prism2_cs.o: 0.2.1-pre22 Loaded
prism2cs_init: dev_info is: prism2_cs
PCI: Enabling device 0000:00:06.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5
usbcore: registered new driver snd-usb-usx2y
Realtime LSM initialized (group 81, mlock=1)
mtrr: no more MTRRs available
ohci_hcd 0000:00:0f.0: wakeup
usb 2-1: new full speed USB device using address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: usb_storage realtime commoncap snd_seq_oss

snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs p80211 ds yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore thermal processor fan button battery ac

CPU:    0
EIP:    0060:[<c01b7e24>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-rc4-mm1-RT-U8.1)

EIP is at up_write+0x1d4/0x202
eax: d4dce000 ebx: 00000292 ecx: d4e18980 edx: d52da030
esi: d4e69e24 edi: d5803400 ebp: d4dcfd6c esp: d4dcfd4c
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process usb-stor (pid: 6630, threadinfo=d4dce000 task=d4dcd8f0)

Stack: d4dcd8f0 d4dcfd78 c02bea7a 00000001 d4dcd8f0 00000292 d4e18980
d5803400
       d4dcfd84 e018e139 d4e18980 d4dcfd84 00000292 d58034b8 d4dcfdac
c022ed0c
       d4e18980 c022ef10 c023166d 00000000 d4e189d4 d4e18980 dcf21000
d5803400
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
 [<c022ed0c>] scsi_dispatch_cmd+0x168/0x218 (40)
 [<c02342e1>] scsi_request_fn+0x1ee/0x42b (52)
 [<c0205606>] blk_insert_request+0xcd/0xfb (44)
 [<c0232f43>] scsi_insert_special_req+0x3b/0x3f (28)
 [<c0233175>] scsi_wait_req+0x61/0x94 (60)
 [<c0235290>] scsi_probe_lun+0x8e/0x240 (68)
 [<c0235883>] scsi_probe_and_add_lun+0xb0/0x1be (48)
 [<c0236009>] scsi_scan_target+0xa4/0x123 (60)
 [<c0236115>] scsi_scan_channel+0x8d/0xa4 (48)
 [<c02361a5>] scsi_scan_host_selected+0x79/0xd4 (44)
 [<c0236231>] scsi_scan_host+0x31/0x33 (28)
 [<e0190cbd>] usb_stor_scan_thread+0x144/0x155 [usb_storage] (96)
 [<c0102305>] kernel_thread_helper+0x5/0xb (723714068)

preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d) .. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 fd af f5 ff e9 35 ff ff ff 0f 0b a5 00 e3 e8

2c c0 e9 da fe ff ff 0f 0b a4 00 e3 e8 2c c0 e9 c4 fe ff ff <0f> 0b 56 02 6f 75 2d c0 e9 3c fe ff ff e8 a8 5b 10 00 e9 22 ff

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#261 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Rui Nuno Capela

One of the signs that there's real trouble in here can be seen on
the following complete dmesg output (which was even a miracle to be captured at all). This shows the complete bootstrap and init sequences and at the end one fatal crash while plugging an USB flash memory stick (usb-storage). This has been already reported earlier yesterday, but I just want to make it here, as the evidence-at-hand.

After this precise occurence, the system becomes very flaky,
unreliable and often ends up freezing to death.

for the sake of testing could you disable CONFIG_USB and see whether the instability is truly directly related to the USB crash, as you suspect? Such a kernel crash can often destabilize other parts of the kernel.

Ingo

#262 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 10 lines · Ingo Molnar
Quoted 7 lines · Rui Nuno Capela

One of the signs that there's real trouble in here can be seen on
the following complete dmesg output (which was even a miracle to be captured at all). This shows the complete bootstrap and init sequences and at the end one fatal crash while plugging an USB flash memory stick (usb-storage). This has been already reported earlier yesterday, but I just want to make it here, as the evidence-at-hand.

Quoted 7 lines
Quoted 2 lines

After this precise occurence, the system becomes very flaky,
unreliable and often ends up freezing to death.

for the sake of testing could you disable CONFIG_USB and see whether the instability is truly directly related to the USB crash, as you suspect? Such a kernel crash can often destabilize other parts of the kernel.

Just tested with CONFIG_USB off, and can't test the usb-storage crash, of course. However, jackd is still freezing to death. No console, nor syslog output can be found. The system just dies sometime after some jack client is launched. Will try further.

I'm on the way to test Thomas Gleixner's patch...

BBL

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]
#263 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 6 lines
Quoted 5 lines

for the sake of testing could you disable CONFIG_USB and see whether the instability is truly directly related to the USB crash, as you suspect? Such a kernel crash can often destabilize other parts of the kernel.

Quoted 7 lines

Just tested with CONFIG_USB off, and can't test the usb-storage crash, of course. However, jackd is still freezing to death. No console, nor syslog output can be found. The system just dies sometime after some jack client is launched. Will try further.

I'm on the way to test Thomas Gleixner's patch...

OK. Thomas patch solves the usb-storage crash, but I added an oneliner change to it, to make it build. Corrected patch is appended.

Thanks.

Signature · 2 lines
rncbc aka Rui Nuno Capela
[email protected]

diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c 2004-10-21
11:45:14.000000000 +0200
@@ -187,7 +187,7 @@
us->srb = srb;

/* wake up the process task */
- up(&(us->sema));
+ complete(&(us->done));

return 0;
}
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c 2004-10-21
11:45:34.000000000 +0200
@@ -299,7 +299,7 @@

for(;;) {
US_DEBUGP("*** thread sleeping.\n");
- if(down_interruptible(&us->sema))
+ if(wait_for_completion_interruptible(&us->done))
break;

US_DEBUGP("*** thread awakened.\n");
@@ -845,7 +845,7 @@
scsi_unlock(us->host); up(&us->dev_semaphore);

- up(&us->sema);
+ complete(&us->done);
wait_for_completion(&us->notify);
}

@@ -941,7 +941,7 @@
}
memset(us, 0, sizeof(struct us_data)); init_MUTEX(&(us->dev_semaphore));
- init_MUTEX_LOCKED(&(us->sema));
+ init_completion(&(us->done));
init_completion(&(us->notify)); init_waitqueue_head(&us->dev_reset_wait); init_waitqueue_head(&us->scsi_scan_wait);
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h 2004-10-21
11:45:13.000000000 +0200
@@ -159,8 +159,8 @@
dma_addr_t iobuf_dma;

/* mutual exclusion and synchronization structures */
- struct semaphore sema; /* to sleep thread on */
- struct completion notify; /* thread begin/end */
+ struct completion done; /* to sleep thread on */
+ struct completion notify; /* thread begin/end */
wait_queue_head_t dev_reset_wait; /* wait during reset */
wait_queue_head_t scsi_scan_wait; /* wait before scanning */
struct completion scsi_scan_done; /* scan thread end */

#264 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Rui Nuno Capela
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

tglx

#265 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

Which is perfectly valid for a semaphore.

#266 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · Christoph Hellwig
Quoted 2 lines

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

Which is perfectly valid for a semaphore.

yes, it is valid and perfectly fine code, but i'm trying to separate out the simple 'mutex' functionality (99% of the semaphore users are just that) and implement a 'counted semaphore' separately. This removes a number of implementational constraints from mutexes.

Ingo

#267 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 6 lines · Ingo Molnar
Quoted 3 lines · Christoph Hellwig
Quoted 2 lines

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

Quoted 6 lines
Quoted 1 line

Which is perfectly valid for a semaphore.

yes, it is valid and perfectly fine code, but i'm trying to separate out the simple 'mutex' functionality (99% of the semaphore users are just that) and implement a 'counted semaphore' separately. This removes a number of implementational constraints from mutexes.

So leave the good old struct semaphore alone and introduce a mutex_t..

#268 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 6 lines · Christoph Hellwig
Quoted 4 lines

yes, it is valid and perfectly fine code, but i'm trying to separate out the simple 'mutex' functionality (99% of the semaphore users are just that) and implement a 'counted semaphore' separately. This removes a number of implementational constraints from mutexes.

So leave the good old struct semaphore alone and introduce a mutex_t..

with nearly 1000 'struct semaphore' references in the kernel and 980 of them being simple mutex use this is rather impractical. So i instead went for safely detecting the 20 non-mutex uses and converting those places. (Btw., 90% of those 20 cases can be detected safely at compile-time (and link-time) by removing DECLARE_MUTEX_LOCKED and making sema_init() a macro that only allows constant values of 0 and 1 and produces a link error for other cases.)

this work is still incomplete so i'm not arguing for upstream inclusion.

(But while we did this a couple of places did turn out to use semaphores for completion which is inefficient - we converted those to completions and are contributing those changes to mainline. But this issue is totally orthogonal to the issue of counted semaphores.)

Ingo

#269 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Christoph Hellwig
Quoted 4 lines · Christoph Hellwig
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

Quoted 9 lines
Quoted 6 lines

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

Which is perfectly valid for a semaphore.

In fact this is used where wait_for_completion() is the correct thing to do. It's not waiting for a resource. It's waiting for completion of a commoand.

tglx

#270 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Thomas Gleixner
Quoted 9 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

Signature · 1 line
Jens Axboe
#271 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · Jens Axboe
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

Quoted 8 lines
Quoted 6 lines

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

It's not!

Quoted 1 line

From the code:

         init_MUTEX_LOCKED(&(us->sema));

This is used to wait for command completion and therefor we have the completion API. It was used this way because the ancestor of completion (sleep_on) was racy !

tglx

#272 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 16 lines · Thomas Gleixner
Quoted 4 lines · Jens Axboe
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

Quoted 8 lines
Quoted 6 lines

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

It's not!

Quoted 7 lines
Quoted 1 line

From the code:

         init_MUTEX_LOCKED(&(us->sema));

This is used to wait for command completion and therefor we have the completion API. It was used this way because the ancestor of completion (sleep_on) was racy !

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

Signature · 1 line
Jens Axboe
#273 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines · Jens Axboe

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

yes, that is perfectly true, and sorry if we gave you the wrong impression.

the goal of these patches is to do a semaphore->completion conversion in cases where the semaphore was used for completion purposes. It's a bit faster and more readable but not a 'bugfix' in any way. (another set of patches are converting sleep_on() uses to wait_event*() plus waitqueues
- those can in fact be considered bugfixes in some cases.)

typically the cases where semaphores are held by one task and released by another task happens coincide with this used-for-completion scenario.

[ the different-owner assert that triggers in my PREEMPT_REALTIME tree is for completely different reasons and has no impact on upstream at all. (It merely means 'Ingo does some weird stuff again, pester him, not others'.) ]

Ingo

#274 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 10 lines · Ingo Molnar
Quoted 3 lines · Jens Axboe

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

yes, that is perfectly true, and sorry if we gave you the wrong impression.

Quoted 8 lines

the goal of these patches is to do a semaphore->completion conversion in cases where the semaphore was used for completion purposes. It's a bit faster and more readable but not a 'bugfix' in any way. (another set of patches are converting sleep_on() uses to wait_event*() plus waitqueues
- those can in fact be considered bugfixes in some cases.)

typically the cases where semaphores are held by one task and released by another task happens coincide with this used-for-completion scenario.

Thanks for the explanation, I can agree with that.

Signature · 1 line
Jens Axboe
#275 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Jens Axboe
Quoted 21 lines · Jens Axboe
Quoted 20 lines · Thomas Gleixner
Quoted 4 lines · Jens Axboe
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

Quoted 8 lines
Quoted 6 lines

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

It's not!

Quoted 1 line

From the code:

         init_MUTEX_LOCKED(&(us->sema));
Quoted 7 lines
Quoted 3 lines

This is used to wait for command completion and therefor we have the completion API. It was used this way because the ancestor of completion (sleep_on) was racy !

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

Yeah, for a semaphore it is, but not for a mutex.

IMHO, this is not clearly seperated and therefor produces a lot of confusion.

tglx

#276 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Thomas Gleixner
Quoted 7 lines
Quoted 3 lines

This is used to wait for command completion and therefor we have the completion API. It was used this way because the ancestor of completion (sleep_on) was racy !

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

Yeah, for a semaphore it is, but not for a mutex.

but mutexes dont exist in upstream Linux as a separate entity. (they exist in my tree but that's another ballgame.)

Quoted 2 lines

IMHO, this is not clearly seperated and therefor produces a lot of confusion.

if used to complete some work then semaphores are indeed a tad unclean and slightly slower than completions - but they are fully correct kernel code. And there are much worse offenders of cleanliness around.

Ingo

#277 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Ingo Molnar
Quoted 2 lines · Thomas Gleixner

Yeah, for a semaphore it is, but not for a mutex.

but mutexes dont exist in upstream Linux as a separate entity. (they exist in my tree but that's another ballgame.)

Mutexes layered on existing semaphores seems convenient at the moment. However a more native mutex mechanism which tracks ownership would provide a basis for PI as well as further instrumentation. This may not be an issue at the present but I don't think it is too far off.

-john

Signature · 1 line
[email protected]
#278 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · john cooper
Quoted 9 lines · Ingo Molnar
Quoted 2 lines · Thomas Gleixner

Yeah, for a semaphore it is, but not for a mutex.

but mutexes dont exist in upstream Linux as a separate entity. (they exist in my tree but that's another ballgame.)

Quoted 9 lines

Mutexes layered on existing semaphores seems convenient at the moment. However a more native mutex mechanism which tracks ownership would provide a basis for PI as well as further instrumentation. This may not be an issue at the present but I don't think it is too far off.

-john

Actually you need to have another kind of semaphore based on a new kind of
wait-queue: Priority based. I.e. the task with the highest priority get woken up first. Then on top of that you build your mutex.

I was planning to start to look at it and try to see if I could get anything to work, but I must admit I haven't got much further than just getting Igno's -U8.1 up running.

An idea I had was to make a macro in list.h called
list_insert_sorted(list, element, condition_statement)
and use that in this kind of wait_queue...

To get a mutex with priority inheritance add an element pointing to the current owner and a field where you store the owners original priority which it has to be set back to when it relases the mutex (I am not sure how this will work out if someone holds several mutexes!)

Regards,
Esben

#279 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Esben Nielsen
Quoted 7 lines · john cooper

Mutexes layered on existing semaphores seems convenient at the moment. However a more native mutex mechanism which tracks ownership would provide a basis for PI as well as further instrumentation. This may not be an issue at the present but I don't think it is too far off.

Quoted 8 lines
Quoted 3 lines

-john

Actually you need to have another kind of semaphore based on a new kind of
wait-queue: Priority based. I.e. the task with the highest priority get woken up first. Then on top of that you build your mutex.

That more/less falls out of the PI mechanism. Though it appears conserving per-mutex data footprint and O(1) behavior are going to be at odds.

Quoted 4 lines

I was planning to start to look at it and try to see if I could get anything to work, but I must admit I haven't got much further than just getting Igno's -U8.1 up running.

I myself wonder whether Ingo is 1 or N people.

Quoted 5 lines

To get a mutex with priority inheritance add an element pointing to the current owner and a field where you store the owners original priority which it has to be set back to when it relases the mutex (I am not sure how this will work out if someone holds several mutexes!)

A task holding several mutexes shouldn't be an issue. Though per task an ownership list needs to be maintained in descending priority order such that the effective PI can be resolved from all task owned mutexes.

Also a multiple ownership model is needed for the case of shared-reader locks. This results in a list of owners where the list element can maintain per-mutex task ownership as well as per-task mutex ownerships.

It is tempting to re-implement the wheel here but existing works are well on their way:

http://developer.osdl.org/dev/robustmutexes

-john

Signature · 1 line
[email protected]
#280 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 34 lines · john cooper
Quoted 9 lines · Esben Nielsen
Quoted 7 lines · john cooper

Mutexes layered on existing semaphores seems convenient at the moment. However a more native mutex mechanism which tracks ownership would provide a basis for PI as well as further instrumentation. This may not be an issue at the present but I don't think it is too far off.

Quoted 8 lines
Quoted 3 lines

-john

Actually you need to have another kind of semaphore based on a new kind of
wait-queue: Priority based. I.e. the task with the highest priority get woken up first. Then on top of that you build your mutex.

That more/less falls out of the PI mechanism. Though it appears conserving per-mutex data footprint and O(1) behavior are going to be at odds.

Quoted 4 lines

I was planning to start to look at it and try to see if I could get anything to work, but I must admit I haven't got much further than just getting Igno's -U8.1 up running.

I myself wonder whether Ingo is 1 or N people.

Quoted 5 lines

To get a mutex with priority inheritance add an element pointing to the current owner and a field where you store the owners original priority which it has to be set back to when it relases the mutex (I am not sure how this will work out if someone holds several mutexes!)

Quoted 4 lines

A task holding several mutexes shouldn't be an issue. Though per task an ownership list needs to be maintained in descending priority order such that the effective PI can be resolved from all task owned mutexes.

Seems it is too coplex model at least for the first step. The one of possible trade-offs coming on mind is to trace the number of resources (mutexes) held by a process and to restore original priority only when resource count reaches 0. This is one of the sollutions accepted by RTOS guys.

The other concern with PI is that most likely PI should be prohibited for utilization with locks which are used in the way similar to "waiting completition" - i.e. if PI is employed on a mutex it is prohibited to release it if a process is not the owner of the mutex.

Quoted 9 lines

Also a multiple ownership model is needed for the case of shared-reader locks. This results in a list of owners where the list element can maintain per-mutex task ownership as well as per-task mutex ownerships.
It is tempting to re-implement the wheel here but existing works are well on their way:

http://developer.osdl.org/dev/robustmutexes

It is definitly non-trivial work to adapt this approach - there are a lot of issues.

Eugeny

Quoted 2 lines

-john

#281 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Eugeny S. Mints
Quoted 4 lines · john cooper

A task holding several mutexes shouldn't be an issue. Though per task an ownership list needs to be maintained in descending priority order such that the effective PI can be resolved from all task owned mutexes.

Seems it is too coplex model at least for the first step. The one of possible trade-offs coming on mind is to trace the number of resources (mutexes) held by a process and to restore original priority only when resource count reaches 0. This is one of the sollutions accepted by RTOS guys.

It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.

Quoted 1 line

The other concern with PI is that most likely PI should be prohibited for utilization with locks which are used in the way similar to "waiting completition" - i.e. if PI is employed on a mutex it is prohibited to release it if a process is not the owner of the mutex.

Yes, that type of usage breaks the notion of ownership. It would be a error for a task to attempt relinquishing a mutex which it had not acquired and was holding at the time of unlock.

Quoted 4 lines
Quoted 1 line

http://developer.osdl.org/dev/robustmutexes

It is definitly non-trivial work to adapt this approach - there are a lot of issues.

I should have qualified that reference. Those folks are addressing more than PI mutexes. Indeed their goal is support of fast user mutexes which offer detection of mutex owners gone astray (exited, killed, etc..). It is the kernel component of the work to which I was referring.

-john

Signature · 1 line
[email protected]
#282 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 8 lines · john cooper

It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock. If you keep it unordered and only search it when you need to recalculate a task's priority after a lock has been released (or priorities have been changed), you pay the cost much less often. Plus, the number of locks held by any given thread should generally be very small.

-Scott

#283 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 12 lines · Scott Wood
Quoted 8 lines · john cooper

It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.

Quoted 6 lines

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock. If you keep it unordered and only search it when you need to recalculate a task's priority after a lock has been released (or priorities have been changed), you pay the cost much less often. Plus, the number of locks held by any given thread should generally be very small.

As to locks held by any given thread - it's not always true - take a look at mm/filemap.c locks nesting map in comments.

Eugeny

#284 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Eugeny S. Mints
Quoted 6 lines · Scott Wood

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock. If you keep it unordered and only search it when you need to recalculate a task's priority after a lock has been released (or priorities have been changed), you pay the cost much less often. Plus, the number of locks held by any given thread should generally be very small.

As to locks held by any given thread - it's not always true - take a look at mm/filemap.c locks nesting map in comments.

I guess it depends on the definition of "very small" and "generally". :-)

A nesting of 5 locks is pushing the limits of "very small", but it's still no big deal to iterate over once in a while.

-Scott

#285 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Scott Wood
Quoted 12 lines · Scott Wood
Quoted 9 lines · john cooper

It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.

Quoted 6 lines

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock. If you keep it unordered and only search it when you need to recalculate a task's priority after a lock has been released (or priorities have been changed), you pay the cost much less often.

That's true for the case where the current priority is somewhere else handy (likely) and we don't need to traverse the list for other reasons such as allowing/disallowing recursive acquisition of a mutex by a given task.

Quoted 3 lines

Plus, the number of locks held by any given thread should generally be very small.

I agree, it is likely in the noise. The list length and manipulation of the mutex waiter list overshadows this.

-john

Signature · 1 line
[email protected]
#286 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines · john cooper
Quoted 2 lines · Scott Wood

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock.

I partially take this back; depending on how it's implemented, you can get away with only adding it to the list once contention occurs.

Quoted 4 lines

That's true for the case where the current priority is somewhere else handy (likely) and we don't need to traverse the list for other reasons such as allowing/disallowing recursive acquisition of a mutex by a given task.

How would maintaining priority order make it faster to check for recursive usage? You'd be looking for a specific mutex rather than the highest priority blocker. You could also check the per-mutex list of owners (which you'll need to implement PI on rwlocks), to avoid needing to add to the locks-held list in non-contended cases.

On uniprocessor, one may wish to turn rwlocks into recursive non-rw mutexes, where recursion checking would use a single owner field.

Also, keeping it in priority order would introduce yet another place that assumes of a linear priority scheme. At some point, it may be desireable to implement other schemes, such as maintaining per-CPU priorities to deal with inheriting from CPU-bound tasks without introducing said tasks' priorities on other CPUs.

-Scott

#287 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · Scott Wood
Quoted 5 lines · john cooper

That's true for the case where the current priority is somewhere else handy (likely) and we don't need to traverse the list for other reasons such as allowing/disallowing recursive acquisition of a mutex by a given task.

How would maintaining priority order make it faster to check for recursive usage?

It wouldn't. My point was an exhaustive traversal may be needed for other reasons with an insertion sort being near free.

Yet considering the cost to maintain these lists in priority order with multiple spinlock acquisition sequences due to how the aggregate data structure must be traversed/ordered, I haven't yet convinced myself either way.

Quoted 3 lines

On uniprocessor, one may wish to turn rwlocks into recursive non-rw mutexes, where recursion checking would use a single owner field.

It isn't obvious to me how this would address the case of a task holding a reader lock on mx-A then blocking on mx-B. Another task attempting to acquire a reader lock on mx-A would block rather than immediately acquiring the lock.

-john

Signature · 1 line
[email protected]
#288 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 4 lines · john cooper
Quoted 3 lines · Scott Wood

How would maintaining priority order make it faster to check for recursive usage?

Quoted 8 lines

It wouldn't. My point was an exhaustive traversal may be needed for other reasons with an insertion sort being near free.

Yet considering the cost to maintain these lists in priority order with multiple spinlock acquisition sequences due to how the aggregate data structure must be traversed/ordered, I haven't yet convinced myself either way.

Another issue is that if you keep them in order, you have to fix the list whenever an owner of a listed mutex changes its priority.

Quoted 7 lines
Quoted 3 lines

On uniprocessor, one may wish to turn rwlocks into recursive non-rw mutexes, where recursion checking would use a single owner field.

It isn't obvious to me how this would address the case of a task holding a reader lock on mx-A then blocking on mx-B. Another task attempting to acquire a reader lock on mx-A would block rather than immediately acquiring the lock.

Yes. However, the contention case should not be optimized at the expense of the common case, which can be faster for non-rwlock implementations when PI is involved. On SMP, you'd be introducing a bottleneck by taking away rwlocks, but on UP it's only an issue when you get preempted or block in a critical section.

There could be problems if some code tries to acquire read locks out-of-order, believing that it can't deadlock that way (if the writers don't nest), but that's a problem anyway unless there's a reasonable way of implementing PI without limiting the number of concurrent readers (they have to be stored somewhere, and the alternatives of setting a hard limit on mutexes-per-thread or doing dynamic allocation inside the lock function are worse).

-Scott

#289 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · Scott Wood
Quoted 5 lines · john cooper

Yet considering the cost to maintain these lists in priority order with multiple spinlock acquisition sequences due to how the aggregate data structure must be traversed/ordered, I haven't yet convinced myself either way.

Another issue is that if you keep them in order, you have to fix the list whenever an owner of a listed mutex changes its priority.

Yes, but my concern was having to backoff in out-of-sequence spinlock acquisition paths. Looking at it again if the canonical lock acquisition sequence is a task's mutex-owned list then a mutex's task-owned list, the nondeterministic backoff (if any) gets pushed to the case of a waiter blocking on the lock.

Quoted 6 lines
Quoted 5 lines

It isn't obvious to me how this would address the case of a task holding a reader lock on mx-A then blocking on mx-B. Another task attempting to acquire a reader lock on mx-A would block rather than immediately acquiring the lock.

Quoted 6 lines

Yes. However, the contention case should not be optimized at the expense of the common case, which can be faster for non-rwlock implementations when PI is involved. On SMP, you'd be introducing a bottleneck by taking away rwlocks, but on UP it's only an issue when you get preempted or block in a critical section.

My concern is removing what should be available reader concurrency for the mutex in question. I can't assess how un/common that may be over all application scenarios.

-john

Signature · 1 line
[email protected]
#290 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 2 lines · john cooper

Yes, but my concern was having to backoff in out-of-sequence spinlock acquisition paths.

Out-of-sequence acquisition is a bug, unless the caller uses trylocks and handles backoff itself.

-Scott

#291 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Scott Wood
Quoted 3 lines · john cooper

Yes, but my concern was having to backoff in out-of-sequence spinlock acquisition paths.

Out-of-sequence acquisition is a bug, unless the caller uses trylocks and handles backoff itself.

Understood -- we may be getting hung up on terminology here.

Rather the issue was whether the nondeterministic out-of-sequence backoff could be pushed to a noncritical path. I believe so. It is further likely a backoff would not be needed as the a path acquiring a mutex's task-owned list lock during a priority promotion scan shouldn't have reason to acquire any task's mutex-owned list lock. The latter list would only need to be locked at time of successful mutex acquisition/free.

-john

Signature · 1 line
[email protected]
#292 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Scott Wood

Esben Nielsen
Work:
Cotas Computer Technology A/S
Paludan Mullersvej 82
8200 Aarhus N
Private
Moellegade 7A, 3., 4
8000 Aarhus C
Phone:
+45 86 12 73 79
Mobile:
+45 27 13 10 05

Quoted 8 lines · Scott Wood
Quoted 3 lines · john cooper
Quoted 2 lines · Scott Wood

If you keep it in priority order, then you're paying the O(n) cost every time you acquire a lock.

I partially take this back; depending on how it's implemented, you can get away with only adding it to the list once contention occurs.

You can implement the full scheduler structure in each mutex. That would be O(1) but would take take quite a lot of memory.

On the other hand a sorted list will not take more memory than now but will appear to be O(n) when inserting into the list. However, on a UP machine no lower priority task will run when higher priority tasks runs. I.e. you will always add to the beginning of the list. That is assuming ofcourse that nobody will sleep while holding a mutex - which is a bad bahaviour. And if you try to take another mutex, while holding one already and you have to block, the holder of the second mutex will be moved up to your priority. I.e. it will block the CPU for any lower priority task...

I don't know what it would be on SMP systems though...

Quoted 5 lines
Quoted 4 lines

That's true for the case whe~re the current priority is somewhere else handy (likely) and we don't need to traverse the list for other reasons such as allowing/disallowing recursive acquisition of a mutex by a given task.

Quoted 9 lines

How would maintaining priority order make it faster to check for recursive usage? You'd be looking for a specific mutex rather than the highest priority blocker. You could also check the per-mutex list of owners (which you'll need to implement PI on rwlocks), to avoid needing to add to the locks-held list in non-contended cases.

On uniprocessor, one may wish to turn rwlocks into recursive non-rw mutexes, where recursion checking would use a single owner field.

Why not use a simple counter? The mutex protects it's own memory area. Anyway, I am not sure recursive acquisition is such a good idea: It will make the mutex more expensive to use and promote sloppy coding where you don't really know what mutexes are held right now. When you are building a subsystem you can send around a flag in the argument saying whether you have taken the lock or not. If you call into other systems, where you can't add a parameter to each function, you should release your mutex(es) anyway! I think it is better that the sloppy coder discoveres that he deadlocks on himself before getting other sub-systems involved :-)

Quoted 6 lines

Also, keeping it in priority order would introduce yet another place that assumes of a linear priority scheme. At some point, it may be desireable to implement other schemes, such as maintaining per-CPU priorities to deal with inheriting from CPU-bound tasks without introducing said tasks' priorities on other CPUs.

I am not sure this at all make sense on a SMP system. For performance reasons I think that one should stick to ordinary semaphores and in a lot of places spin-locks on such a system. Even with a dedicated RTOS you have to design your system from the bottum up to get a good real-time behaviour - and it depends a lot on the application of which you can only have one! That is very far from the world of SMP servers.

The ones who can use all the fancy mutexes are really embedded developer (like myself) who need a robust RTOS but also drivers for a lot of hardware, a good TCP/IP stack, firewall, good filesystems etc. which the commercial vendors have a hard time delivering all at once.

On the desktop it can lead to good performance of multimedia but as soon as you want to use two applications, which considers themselves multimedia and thus gives themselves high priority, it wont work.

I must also say, that from my perspective low latencies is not the issue. The issue is predictability: I must be able to create threads and know they can't all the sudden be preempted by all kinds of things. I.e. if I give them higher priority than all the "normal" stuff and all shared resources between my tasks and the "normal" stuff are locked with mutexes using prirority inheritance and only for fixed amount of time, I am in the clear. It is also important that all interrupts and spin-locks are only held for a fixed amount of time - but as long as that time is lower than the maximum latency and is bounded in occurance I don't really care. Forinstance a driver servicing a serial channel wont hurt being run in interrupt context as it is really limited how much CPU it can take overall.

Quoted 1 line

-Scott

Esben

#293 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 2 lines · Esben Nielsen

You can implement the full scheduler structure in each mutex. That would be O(1) but would take take quite a lot of memory.

Are you talking about the thread's locks-held list, or the mutex's blocked-threads list? In the latter case, you could cut down on the memory usage by allocating one such structure for each thread upon creation, placing it into a pool, and associating them with a mutex when it's contended (as you can't have more contended mutexes than you have threads). It's still a lot heavier than a linked list, though.

In either case, you'd need to do whatever adjustments to the scheduler's data structures are necessary whenever a task's priority changes (including via PI). It's worth it for at least one of the lists, as if neither locks-held nor threads-blocked is kept in order, priority recalculation becomes O(n^2) to find the highest priority blocker among all held mutexes. Ordering threads-blocked seems to make more sense, as you don't have the imbalance between the frequency adding to the list and searching the list.

Quoted 6 lines

On the other hand a sorted list will not take more memory than now but will appear to be O(n) when inserting into the list. However, on a UP machine no lower priority task will run when higher priority tasks runs. I.e. you will always add to the beginning of the list. That is assuming ofcourse that nobody will sleep while holding a mutex - which is a bad bahaviour.

It's bad, but inevitable if this is also used to provide PI mutexes to userspace.

Quoted 6 lines
Quoted 3 lines

On uniprocessor, one may wish to turn rwlocks into recursive non-rw mutexes, where recursion checking would use a single owner field.

Why not use a simple counter?

You'd need a counter as well, but you first have to check the owner to make sure that the count reflects the calling thread's activity rather than some other thread.

Quoted 4 lines

The mutex protects it's own memory area.
Anyway, I am not sure recursive acquisition is such a good idea: It will make the mutex more expensive to use and promote sloppy coding where you don't really know what mutexes are held right now.

I agree, but current code assumes rwlocks can be recursively obtained for reading (unless that's changed recently).

Quoted 6 lines

I am not sure this at all make sense on a SMP system. For performance reasons I think that one should stick to ordinary semaphores and in a lot of places spin-locks on such a system. Even with a dedicated RTOS you have to design your system from the bottum up to get a good real-time behaviour - and it depends a lot on the application of which you can only have one! That is very far from the world of SMP servers.

Things get weird on SMP, but it's possible to produce reasonable real-time behavior, and there are people out there who are interested in it.

Quoted 4 lines

The ones who can use all the fancy mutexes are really embedded developer (like myself) who need a robust RTOS but also drivers for a lot of hardware, a good TCP/IP stack, firewall, good filesystems etc. which the commercial vendors have a hard time delivering all at once.

And some embedded devices also need a lot of CPU power, and some of those use SMP.

Quoted 3 lines

On the desktop it can lead to good performance of multimedia but as soon as you want to use two applications, which considers themselves multimedia and thus gives themselves high priority, it wont work.

It can be made to work if you have CPU reservations, or some other way of ensuring that the applications take their CPU in appropriately sized chunks.

-Scott

#294 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Esben Nielsen
Quoted 4 lines · Esben Nielsen

Anyway, I am not sure recursive acquisition is such a good idea: It will make the mutex more expensive to use and promote sloppy coding where you don't really know what mutexes are held right now.

In my experience I haven't quite found this to be the case. Rather allowing a lock/mutex/etc.. to be recursively acquired within a given path can greatly simplify APIs. Such as cases where a primitive acquires a lock internally which is also know by and suited to protect data in the caller's context. This avoids the "who has the lock?" information which must otherwise get stuffed into the API. Nested function calls simply observe correct lock usage at their respective levels and all unwinds correctly.

The one notable place where this doesn't work is where locks must be conditionally acquired in an out-of-order sequence. However often these cases can be pushed out of the externally visible API. Another operational consideration is maintaining debug information in the lock. Keeping track of where each lock acquisition was made is at odds with a fixed sized lock data footprint. Still recursive acquisitions scale only with available stack space so a fair upper limit approximation is possible when running on fixed size stacks. Note I'm refering to single-owner spinlocks/mutexes here rather than reader/write locks.

Quoted 3 lines

I think it is better that the sloppy coder discoveres that he deadlocks on himself before getting other sub-systems involved :-)

I agree. But I don't think the above precludes doing so. Detecting violations of unbalanced lock/unlock calls isn't really different than for non-recursive primitives.

-john

Signature · 1 line
[email protected]
#295 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to john cooper
Quoted 14 lines · john cooper
Quoted 10 lines · Eugeny S. Mints
Quoted 4 lines · john cooper

A task holding several mutexes shouldn't be an issue. Though per task an ownership list needs to be maintained in descending priority order such that the effective PI can be resolved from all task owned mutexes.

Seems it is too coplex model at least for the first step. The one of possible trade-offs coming on mind is to trace the number of resources (mutexes) held by a process and to restore original priority only when resource count reaches 0. This is one of the sollutions accepted by RTOS guys.

Quoted 8 lines

It would seem a mutex ownership list still needs to be maintained. Doing so in unordered priority will give a small fixed insertion time, but will require an exhaustive search in order to calculate maximum priority. Doing so in priority order will require an average of #mutex_owned / 2 for the insertion, and gives a fixed time for maximum priority calculation. The latter appears to offer a performance benefit to the degree the incoming priorities are random.

Yes, definilty, I 100% agree with you - I have _not_ disputed the priority list approach at all.

Quoted 7 lines
Quoted 1 line

The other concern with PI is that most likely PI should be prohibited for utilization with locks which are used in the way similar to "waiting completition" - i.e. if PI is employed on a mutex it is prohibited to release it if a process is not the owner of the mutex.

Yes, that type of usage breaks the notion of ownership. It would be a error for a task to attempt relinquishing a mutex which it had not acquired and was holding at the time of unlock.

exactly

Quoted 4 lines
Quoted 4 lines
Quoted 1 line

http://developer.osdl.org/dev/robustmutexes

Quoted 8 lines
Quoted 1 line

It is definitly non-trivial work to adapt this approach - there are a lot of issues.

I should have qualified that reference. Those folks are addressing more than PI mutexes. Indeed their goal is support of fast user mutexes which offer detection of mutex owners gone astray (exited, killed, etc..). It is the kernel component of the work to which I was referring.

Ok, I've also talked about kernel component not user space one. User space approach with robustness, fast uncontented obtaining, etc looks very attractive but both kernel and user space parts have their issues - though I took a glance to the project about 2 months ago.

Eugeny

#296 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Eugeny S. Mints
Quoted 5 lines · Eugeny S. Mints

Seems it is too coplex model at least for the first step. The one of possible trade-offs coming on mind is to trace the number of resources (mutexes) held by a process and to restore original priority only when resource count reaches 0. This is one of the sollutions accepted by RTOS guys.

That complicates analysis, though, since you now have to look at all critical sections that the shared-with-high-priority-threads critical sections nest in. IMHO, it's important that the inherited priority be given up as soon as the resource is released.

-Scott

#297 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Thomas Gleixner
Quoted 26 lines · Thomas Gleixner
Quoted 25 lines · Jens Axboe
Quoted 23 lines · Thomas Gleixner
Quoted 4 lines · Jens Axboe
Quoted 3 lines · Thomas Gleixner
Quoted 1 line · Rui Nuno Capela

[<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

Quoted 8 lines
Quoted 6 lines

As I already pointed out, this is a problem due to up(sema) in queuecommand. That's one of the semaphore abuse points, which needs to be fixed.

The problem is that semaphores are hold by Process A and released by Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

It's not!

Quoted 1 line

From the code:

         init_MUTEX_LOCKED(&(us->sema));

This is used to wait for command completion and therefor we have the completion API. It was used this way because the ancestor of completion (sleep_on) was racy !

Quoted 8 lines
Quoted 3 lines

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

Yeah, for a semaphore it is, but not for a mutex.

IMHO, this is not clearly seperated and therefor produces a lot of confusion.

Semaphore and mutex has always been the same thing in Linux. Apparently this isn't so in Ingos tree, you should make a clear distinction on which you are discussing.

Signature · 1 line
Jens Axboe
#298 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Jens Axboe
Quoted 3 lines

IMHO, this is not clearly seperated and therefor produces a lot of confusion.

Semaphore and mutex has always been the same thing in Linux. Apparently this isn't so in Ingos tree, you should make a clear distinction on which you are discussing.

I agree, but this thread is discussing Ingo's tree :)

I know that semaphores and mutexes are the same, but that's something which should be seperated IMHO.

Ingo's changes reviel a couple of places where completion or wait_event is more clean, than using a mutex. That's all I'm talking about. Sorry, if I did not express it clearly enough or even used a wrong expression.

The points, which we identify are not wrong from the view point when they were coded. They use a mutex to wait for completion, which is functional by the mutex implementation and common use in the kernel.

Part of this discussion is the given mixup in the kernel, which is functionally correct, but if a mutex is changed to a real mutex then it is wrong in the semantical sense.

tglx

#299 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Jens Axboe
Quoted 3 lines · Jens Axboe

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

A lot of things are perfectly "valid" in the Linux kernel regarding stuff like that are a bit irregular. But the preemption work about to stress these things in ways that was never designed to which is why these patches are needed. Having a clear use of various locking conventions is key to getting this system to behave in a predictable manner. Quite simply, Linux was never targetted to do this and the sloppiness is showing so it's got to be removed.

bill

#300 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 5 lines · Bill Huey
Quoted 3 lines · Jens Axboe

I didn't look at the USB code, I'm just saying that it's perfectly valid use of a semaphore the pattern you describe (process A holding it, process B releasing it).

Quoted 7 lines

A lot of things are perfectly "valid" in the Linux kernel regarding stuff like that are a bit irregular. But the preemption work about to stress these things in ways that was never designed to which is why these patches are needed. Having a clear use of various locking conventions is key to getting this system to behave in a predictable manner. Quite simply, Linux was never targetted to do this and the sloppiness is showing so it's got to be removed.

I have to disagree, I don't think the above use is either convoluted or sloppy in any way. Now that we have the completion structure, certain things are surely better implemented as such. But the old use is perfectly valid and logical, imho.

Signature · 1 line
Jens Axboe
#301 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Jens Axboe
Quoted 7 lines · Bill Huey

A lot of things are perfectly "valid" in the Linux kernel regarding stuff like that are a bit irregular. But the preemption work about to stress these things in ways that was never designed to which is why these patches are needed. Having a clear use of various locking conventions is key to getting this system to behave in a predictable manner. Quite simply, Linux was never targetted to do this and the sloppiness is showing so it's got to be removed.

Quoted 4 lines

I have to disagree, I don't think the above use is either convoluted or sloppy in any way. Now that we have the completion structure, certain things are surely better implemented as such. But the old use is perfectly valid and logical, imho.

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

bill

#302 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 15 lines · Bill Huey
Quoted 9 lines · Jens Axboe
Quoted 7 lines · Bill Huey

A lot of things are perfectly "valid" in the Linux kernel regarding stuff like that are a bit irregular. But the preemption work about to stress these things in ways that was never designed to which is why these patches are needed. Having a clear use of various locking conventions is key to getting this system to behave in a predictable manner. Quite simply, Linux was never targetted to do this and the sloppiness is showing so it's got to be removed.

Quoted 4 lines

I have to disagree, I don't think the above use is either convoluted or sloppy in any way. Now that we have the completion structure, certain things are surely better implemented as such. But the old use is perfectly valid and logical, imho.

Quoted 6 lines

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Signature · 1 line
Jens Axboe
#303 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 8 lines · Jens Axboe
Quoted 6 lines · Bill Huey

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Quoted 6 lines

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Well, this is something that's got to be considered by the larger Linux community and whether these conventions are to be kept or removed. It's a larger issue than what can be address in Ingo's preemption patch, but with inevitable need for something like this in the kernel (hard RT) it's really unavoidable collision. IMO, it's got to go, which is a nasty change.

bill

#304 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 16 lines · Bill Huey
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Bill Huey

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Quoted 6 lines

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Quoted 7 lines

Well, this is something that's got to be considered by the larger Linux community and whether these conventions are to be kept or removed. It's a larger issue than what can be address in Ingo's preemption patch, but with inevitable need for something like this in the kernel (hard RT) it's really unavoidable collision. IMO, it's got to go, which is a nasty change.

Hey, let's stop this here.

You are both (in)correct :)

1. It makes no sense to discuss, why X has been considered correct for time T.

2. Counted semaphores are a valid use and should be marked explicit as counted semaphores.

3. Using mutexes and semaphores for event and completion signalling should be converted to the appropriate interfaces.

A bunch of work, but not really hard.

tglx

#305 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 7 lines · Thomas Gleixner

Hey, let's stop this here.

You are both (in)correct :)

1. It makes no sense to discuss, why X has been considered correct for time T.

Quoted 7 lines

2. Counted semaphores are a valid use and should be marked explicit as counted semaphores.

3. Using mutexes and semaphores for event and completion signalling should be converted to the appropriate interfaces.

A bunch of work, but not really hard.

What's the verdict ? leave the lock detector alone or change it ?

bill

#306 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Thomas Gleixner
Quoted 25 lines · Thomas Gleixner
Quoted 16 lines · Bill Huey
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Bill Huey

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Quoted 6 lines

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Quoted 7 lines

Well, this is something that's got to be considered by the larger Linux community and whether these conventions are to be kept or removed. It's a larger issue than what can be address in Ingo's preemption patch, but with inevitable need for something like this in the kernel (hard RT) it's really unavoidable collision. IMO, it's got to go, which is a nasty change.

Quoted 6 lines

Hey, let's stop this here.

You are both (in)correct :)

1. It makes no sense to discuss, why X has been considered correct for time T.

Because it is correct. Debating that it's now incorrect because it inconveniently happens to make some detection scheme harder is silly.

Quoted 2 lines

2. Counted semaphores are a valid use and should be marked explicit as counted semaphores.

Indeed

Quoted 2 lines

3. Using mutexes and semaphores for event and completion signalling should be converted to the appropriate interfaces.

Agree. Do you test all your conversions? Whole-sale conversions like this tend to break at least some of the drivers. And that's totally unacceptable, breaking a working solution because of something that's not really a bug.

Quoted 1 line

A bunch of work, but not really hard.

Not if you don't test it.

Signature · 1 line
Jens Axboe
#307 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 8 lines · Bill Huey
Quoted 6 lines · Jens Axboe

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Quoted 6 lines

Well, this is something that's got to be considered by the larger Linux community and whether these conventions are to be kept or removed. It's a larger issue than what can be address in Ingo's preemption patch, but with inevitable need for something like this in the kernel (hard RT) it's really unavoidable collision. IMO, it's got to go, which is a nasty change.

But this is a non-fatal case. I'll see if I can change this logic to not completely die when this case is detected.

bill

#308 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 16 lines · Bill Huey
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Bill Huey

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Quoted 6 lines

Linux semaphores (being counted) have always been a fine fit for things like the loop use, where you get to down it 10 times because you have 10 items pending. I know this isn't the traditional mutex and that it doesn't protect data as such, but is was never abuse. It isn't overload. Doing it with a traditional mutex (I'm assuming this is what mutex_t is in Ingos tree) would be overload and a bad idea, indeed.

Quoted 6 lines

Well, this is something that's got to be considered by the larger Linux community and whether these conventions are to be kept or removed. It's a larger issue than what can be address in Ingo's preemption patch, but with inevitable need for something like this in the kernel (hard RT) it's really unavoidable collision. IMO, it's got to go, which is a nasty change.

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

Signature · 1 line
Jens Axboe
#309 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

no, this is no reason at all. I'm really sorry this issue came up in this context because now people appear to be arguing this as some sort of policy issue, implying that is somehow improper to use mutexes instead of completions, which it clearly is _not_. I very much wanted to avoid this particular type of flamewar :-)

Using mutexes for completion purposes is perfectly fine kernel code. Full stop.

Using completions instead of mutexes in certain cases has some minor advantages for two simple reasons: it's slighly faster and it's also more readable.

here's an example: initially i made the scheduler's migration logic use semaphores in that fashion and Linus made me change it to completions, because, and i quote Linus here:

[...]
Btw, should you not use completions here?

Completions are optimized for the sleep (ie contention) case, while semaphores are optimized for the non-contention case. It also makes more "sense" from a conceptual angle (you're waiting for something to complete, not asking for an exclusive thing).
[...]

and i have to say the migration code did become cleaner. To signal some sort of event it's a more intuitive _symbol_ _name_ to use 'complete()' and 'wait_for_completion()' than to use 'up()' and 'down()'.

[ If you truly do not agree with this contention then please just look at one simple conversion we did and check out the previous and the new logic, by reading the full previous code and the full resulting code. I do believe that if anyone at that point still thinks that the semaphore-based code is just as readable (in that context!) as the completion-based code that then his brains are not made of neurons but silicon :) ]

but it has never been kernel policy to not allow the use of mutexes that way! In some cases it's somewhat cleaner to use completions (and if something is cleaner in Linux then in most cases it's faster as well), but it's a judgement thing just like it's judgement thing whether to use kmalloc() or get_free_pages(). Both are correct for the generic problem of 'allocate some kernel RAM', but optimized for two different types of uses.

Ingo

#310 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 36 lines · Ingo Molnar
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

no, this is no reason at all. I'm really sorry this issue came up in this context because now people appear to be arguing this as some sort of policy issue, implying that is somehow improper to use mutexes instead of completions, which it clearly is _not_. I very much wanted to avoid this particular type of flamewar :-)

Using mutexes for completion purposes is perfectly fine kernel code. Full stop.

Using completions instead of mutexes in certain cases has some minor advantages for two simple reasons: it's slighly faster and it's also more readable.

here's an example: initially i made the scheduler's migration logic use semaphores in that fashion and Linus made me change it to completions, because, and i quote Linus here:

[...]
Btw, should you not use completions here?

Completions are optimized for the sleep (ie contention) case, while semaphores are optimized for the non-contention case. It also makes more "sense" from a conceptual angle (you're waiting for something to complete, not asking for an exclusive thing).
[...]

and i have to say the migration code did become cleaner. To signal some sort of event it's a more intuitive _symbol_ _name_ to use 'complete()' and 'wait_for_completion()' than to use 'up()' and 'down()'.

Quoted 7 lines

[ If you truly do not agree with this contention then please just look at one simple conversion we did and check out the previous and the new logic, by reading the full previous code and the full resulting code. I do believe that if anyone at that point still thinks that the semaphore-based code is just as readable (in that context!) as the completion-based code that then his brains are not made of neurons but silicon :) ]

I fully agree with everything in your mail so far. What annoyed me is some people advocating their changes under the false pretense that existing use was broken, which it isn't.

completions _do_ make cleaner code for the intended case. But your writing above is very clear and already explains that very well.

Lets put the issue to rest and get back to more productive work!

Signature · 1 line
Jens Axboe
#311 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines · Jens Axboe

I fully agree with everything in your mail so far. What annoyed me is some people advocating their changes under the false pretense that existing use was broken, which it isn't.

yeah, and i have to say that such advocacy mostly comes from the natural desire to solve those _other_ problems that non-standard locking designs have with Linux mutexes. But those problems are that of the other trees alone, not upstream's :) Suggesting that those problems are in any way upstream's problem, even if well-intentioned, can be quite offensive.

Quoted 4 lines

completions _do_ make cleaner code for the intended case. But your writing above is very clear and already explains that very well.

Lets put the issue to rest and get back to more productive work!

/me rejoices :)

Ingo

#312 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Jens Axboe
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

bill

#313 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

*plonk*

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Signature · 1 line
Jens Axboe
#314 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 10 lines · Jens Axboe
Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

Quoted 4 lines

*plonk*

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the crap with implied personal attacks like the above. If you hadn't pull the discussion to that point, I wouldn't have reacted that way. It's completely juvenile behavior from you and you can't expect me or anybody else to take it sitting down.

bill

#315 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · Bill Huey
Quoted 4 lines · Jens Axboe

*plonk*

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the crap with implied personal attacks like the above. If you hadn't pull the discussion to that point, I wouldn't have reacted that way. It's completely juvenile behavior from you and you can't expect me or anybody else to take it sitting down.

This is also email, so misunderstanding and misinterpretations do happen. If that's the case, then I'm sorry to misunderstand you and then get upset, but next time be more specific about improving this code and other things related to it.

bill

#316 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 13 lines · Bill Huey
Quoted 11 lines · Bill Huey
Quoted 4 lines · Jens Axboe

*plonk*

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the crap with implied personal attacks like the above. If you hadn't pull the discussion to that point, I wouldn't have reacted that way. It's completely juvenile behavior from you and you can't expect me or anybody else to take it sitting down.

Quoted 4 lines

This is also email, so misunderstanding and misinterpretations do happen. If that's the case, then I'm sorry to misunderstand you and then get upset, but next time be more specific about improving this code and other things related to it.

I've been as clear as I know how on the matter of semaphore use in Linux. I've made no comments at all on improving your deadlock detection scheme.

Signature · 1 line
Jens Axboe
#317 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 3 lines · Jens Axboe

I've been as clear as I know how on the matter of semaphore use in Linux. I've made no comments at all on improving your deadlock detection scheme.

True, but "...deadlock detection breaks" is a negative comment about the deadlock detector without a positive suggestion to change it, is it not ? if so, then suggest a change to be made and it'll get implementated somehow.

bill

#318 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 9 lines · Bill Huey
Quoted 3 lines · Jens Axboe

I've been as clear as I know how on the matter of semaphore use in Linux. I've made no comments at all on improving your deadlock detection scheme.

True, but "...deadlock detection breaks" is a negative comment about the deadlock detector without a positive suggestion to change it, is it not ? if so, then suggest a change to be made and it'll get implementated somehow.

It's a statement about the deadlock detection which is true, it's not a negative comment. A negative comment would be something ala "the deadlock detection code is crap". Note, to avoid further confusion in this thread: I have not read the deadlock detection code, nor do I intend to. The sentence is only an example of what a negative comment would look like, in no way does it reflect my view of the deadlock detection code. End disclaimer.

As I said, I have no personal motivation to work on the deadlock detection. My interest in the thread pertained only to code in the kernel and its use of semaphores - something that we already cleared up many mails ago.

So, please, lets just end it here. This branch of the thread has already dragged on for way too long.

Signature · 1 line
Jens Axboe
#319 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 13 lines · Bill Huey
Quoted 12 lines · Jens Axboe
Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

*plonk*

Quoted 8 lines
Quoted 2 lines

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the crap with implied personal attacks like the above. If you hadn't pull the discussion to that point, I wouldn't have reacted that way. It's completely juvenile behavior from you and you can't expect me or anybody else to take it sitting down.

What mails are you reading?!

Personally, I could not care less about the deadlock detection. If it's a priority for you personally or due to corporate reasons, fine, but don't involve me.

I have made no attacks on your deadlock detection other than to state the obvious - that it has cases where it triggers on perfectly legit code. If you read that as "implied personal attacks" or "juvenile behaviour" then you need to grow thicker skin. The only personal attacks here are the ones coming from you.

Signature · 1 line
Jens Axboe
#320 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 13 lines · Bill Huey
Quoted 12 lines · Jens Axboe
Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

*plonk*

Quoted 8 lines
Quoted 2 lines

If you can't stand criticism without resorting to feeble personal attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the crap with implied personal attacks like the above. If you hadn't pull the discussion to that point, I wouldn't have reacted that way. It's completely juvenile behavior from you and you can't expect me or anybody else to take it sitting down.

Stop that now !

You have started personal attacks.

This flame was already off. What the heck are you trying to achieve with this ?

tglx

#321 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

oh no!

/me watches the flames fan out again as a bushfire

do you expect there to be any meaningful technical discussion resulting out of you calling Jens' (valid) comments 'idiot attacks'? Fact is, upstream couldnt care less about PREEMPT_REALTIME and/or the deadlock detector at this point. Upstream _never_ cared about any not yet merged (and in this case, completely unfinished) feature.

/me apologizes to Jens

Ingo

#322 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 8 lines · Bill Huey
Quoted 2 lines · Jens Axboe

It has to go, why? Because your deadlock detection breaks? Doesn't seem a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is irrelevant to the current work that's being done. And your idiot attacks against it doesn't correct these issues nor does it gain credibility with the audience that does find it useful.

*plonk*

#323 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Bill Huey (hui)
Quoted 9 lines · Bill Huey (hui)

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Could you please define "completion" for me in this context?

Thanks.

#324 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

Quoted 11 lines · Timothy Miller
Quoted 7 lines · Bill Huey (hui)

You use a semaphore to protect data, a completion isn't protecting data but preserving a certain kind of wait ordering in the code. The possibility of overloading the current mutex_t for PI makes for a conceptual mismatch when used in this case since having a kind of priority for completions is a bit odd. It's better to flat out use a completion instead, IMO.

Could you please define "completion" for me in this context?

A triggers B to exit and must wait until B has exited. It waits for completion of exit.

A triggers B to execute a command and must wait until B has done so. It waits for completion of the command.

Mutexes are used for that, but that's not the intended functionality of a mutex. Of course it works as long as you do no owner checks on the mutexes.

A {
init_MUTEX_LOCKED(m)
trigger B
down(m) <----- recursion, because A owns it already
}

The completion is designed for that and should be used IMHO. Mutexe were used for that, because the ancestors of completion, sleep_on...(), are racy.

tglx

#325 lore raw

Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

In reply to Rui Nuno Capela

On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:

Can you try that one ?

diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c 2004-10-21
11:45:14.000000000 +0200
@@ -187,7 +187,7 @@
us->srb = srb;

/* wake up the process task */
- up(&(us->sema));
+ complete(&(us->done));

return 0;
}
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c 2004-10-21
11:45:34.000000000 +0200
@@ -299,7 +299,7 @@

for(;;) {
US_DEBUGP("*** thread sleeping.\n");
- if(down_interruptible(&us->sema))
+ if(wait_for_completion_interruptible(&us->done))
break;

US_DEBUGP("*** thread awakened.\n");
@@ -941,7 +941,7 @@
}
memset(us, 0, sizeof(struct us_data)); init_MUTEX(&(us->dev_semaphore));
- init_MUTEX_LOCKED(&(us->sema));
+ init_completion(&(us->done));
init_completion(&(us->notify)); init_waitqueue_head(&us->dev_reset_wait); init_waitqueue_head(&us->scsi_scan_wait);
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h 2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h 2004-10-21
11:45:13.000000000 +0200
@@ -159,8 +159,8 @@
dma_addr_t iobuf_dma;

/* mutual exclusion and synchronization structures */
- struct semaphore sema; /* to sleep thread on */
- struct completion notify; /* thread begin/end */
+ struct completion done; /* to sleep thread on */
+ struct completion notify; /* thread begin/end */
wait_queue_head_t dev_reset_wait; /* wait during reset */
wait_queue_head_t scsi_scan_wait; /* wait before scanning */
struct completion scsi_scan_done; /* scan thread end */