Linus 2.6.23-rc1

Linus 2.6.23-rc1

[Linus Torvalds]

Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.

And it has a *ton* of changes as usual for the merge window, way too much 
for me to be able to post even just the shortlog or diffstat on the 
mailing list (but I had many people who wanted to full logs to stay 
around, so you'll continue to see those being uploaded to kernel.org).

Lots of architecture updates (for just about all of them - x86[-64], arm, 
alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
(again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
firewire, i2c, you name it).

Filesystems, VM, networking, ACPI, it's all there. And virtualization all 
over the place (kvm, lguest, Xen).

Notable new things might be the merge of the cfs scheduler, and the UIO 
driver infrastructure might interest some people.

Oh, and I personally like how "sendfile" is now totally gone internally, 
and the kernel now ends up doing all that with splice insted. Good 
riddance, although we'll obvously end up supporting the old user level 
interfaces for a long time.

So give it all a good whacking, and report back about all the neat new 
features!

		Linus

Re: Linus 2.6.23-rc1

[Andre Noll]

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

On 14:04, Linus Torvalds wrote:

> So give it all a good whacking, and report back about all the neat new 
> features!

Does overlapping sections count as a new feature? ;)

  gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1  -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o arch/x86_64/vdso/vdso.so
/usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
collect2: ld returned 1 exit status
make[3]: *** [arch/x86_64/vdso/vdso.so] Error 1
make[2]: *** [arch/x86_64/vdso] Error 2
make[1]: *** [_all] Error 2
make: *** [all] Error 2

This is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

.config below.

Regards
Andre


#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 00:04:38 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_NR_QUICK=2
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CPUSETS=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="initramfs.txt"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set

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

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
CONFIG_NUMA=y
# CONFIG_K8_NUMA is not set
CONFIG_NODES_SHIFT=6
CONFIG_X86_64_ACPI_NUMA=y
# CONFIG_NUMA_EMU is not set
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
CONFIG_DISCONTIGMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_DISCONTIGMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_NEED_MULTIPLE_NODES=y
# CONFIG_SPARSEMEM_STATIC is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y
CONFIG_NR_CPUS=16
CONFIG_PHYSICAL_ALIGN=0x200000
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
# CONFIG_X86_MCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_START=0x200000
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_K8_NB=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
CONFIG_GENERIC_PENDING_IRQ=y

#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_ACPI_CPUFREQ=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_HT_IRQ=y

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

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP 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_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
CONFIG_IP_DCCP=y
CONFIG_INET_DCCP_DIAG=y
CONFIG_IP_DCCP_ACKVEC=y

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=y
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
CONFIG_IP_DCCP_TFRC_LIB=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_SCTP=y
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC 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_ECONET is not set
# CONFIG_WAN_ROUTER is not set

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

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# 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 is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
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 is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

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

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

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# 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=y
# CONFIG_CHR_DEV_SCH is not set

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

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_LIBSAS_DEBUG=y
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
CONFIG_BLK_DEV_3W_XXXX_RAID=y
CONFIG_SCSI_3W_9XXX=y
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=y
# CONFIG_AIC94XX_DEBUG is not set
# CONFIG_SCSI_ARCMSR is not set
CONFIG_MEGARAID_NEWGEN=y
# CONFIG_MEGARAID_MM is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=y
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA 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_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
CONFIG_SATA_NV=y
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
CONFIG_SATA_SIL=y
CONFIG_SATA_SIL24=y
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
CONFIG_MD_RAID0=y
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
CONFIG_MD_MULTIPATH=y
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=y
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_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=y
# CONFIG_FORCEDETH_NAPI is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
CONFIG_E100=y
# 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_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
CONFIG_SKGE=y
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
CONFIG_BNX2=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set

#
# USB Network Adapters
#
# 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_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=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=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=y

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

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

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_SI=y
CONFIG_IPMI_WATCHDOG=y
# CONFIG_IPMI_POWEROFF is not set
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_FB is not set

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

#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

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

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

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

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX 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_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4DEV_FS=y
CONFIG_EXT4DEV_FS_XATTR=y
# CONFIG_EXT4DEV_FS_POSIX_ACL is not set
# CONFIG_EXT4DEV_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=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=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
# CONFIG_ROOT_NFS is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_RPCSEC_GSS_SPKM3=y
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
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=y
# 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=y
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=y

#
# Distributed Lock Manager
#
CONFIG_DLM=y
# CONFIG_DLM_DEBUG is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_BUGVERBOSE is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_X86_64 is not set
CONFIG_CRYPTO_CAST5=y
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_HW=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y


-- 
The only person who always got his work done by Friday was Robinson Crusoe

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

Re: Linus 2.6.23-rc1

[Andi Kleen]

On Monday 23 July 2007 00:10:01 Andre Noll wrote:
> On 14:04, Linus Torvalds wrote:
> 
> > So give it all a good whacking, and report back about all the neat new 
> > features!
> 
> Does overlapping sections count as a new feature? ;)
> 
>   gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1  -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o arch/x86_64/vdso/vdso.so
> /usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
> collect2: ld returned 1 exit status
> make[3]: *** [arch/x86_64/vdso/vdso.so] Error 1
> make[2]: *** [arch/x86_64/vdso] Error 2
> make[1]: *** [_all] Error 2
> make: *** [all] Error 2


Does this patch fix it?

-Andi


Increase VDSO_TEXT_OFFSET for ancient binutils

For some reason old binutils genertate larger headers so
increase the text offset of the vdso to avoid linker errors.

Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/arch/x86_64/vdso/voffset.h
===================================================================
--- linux.orig/arch/x86_64/vdso/voffset.h
+++ linux/arch/x86_64/vdso/voffset.h
@@ -1 +1 @@
-#define VDSO_TEXT_OFFSET 0x500
+#define VDSO_TEXT_OFFSET 0x600

Re: Linus 2.6.23-rc1

[Andre Noll]

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

On 00:22, Andi Kleen wrote:
> > /usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
> 
> Does this patch fix it?

Nope, with 0x600 I still get the same error. But it helped to further
increase VDSO_TEXT_OFFSET to 0xc00. I tried 0x700, 0x800,... and 0xc00
is the smallest value in this series that makes the error go away, i.e.
the patch below works for me.

Thanks
Andre


diff --git a/arch/x86_64/vdso/voffset.h b/arch/x86_64/vdso/voffset.h
index 5304204..61667d5 100644
--- a/arch/x86_64/vdso/voffset.h
+++ b/arch/x86_64/vdso/voffset.h
@@ -1 +1 @@
-#define VDSO_TEXT_OFFSET 0x500
+#define VDSO_TEXT_OFFSET 0xc00

-- 
The only person who always got his work done by Friday was Robinson Crusoe

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

Re: Linus 2.6.23-rc1

[Andi Kleen]

On Monday 23 July 2007 01:23:38 Andre Noll wrote:
> On 00:22, Andi Kleen wrote:
> > > /usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
> > 
> > Does this patch fix it?
> 
> Nope, with 0x600 I still get the same error. But it helped to further
> increase VDSO_TEXT_OFFSET to 0xc00. I tried 0x700, 0x800,... and 0xc00
> is the smallest value in this series that makes the error go away, i.e.
> the patch below works for me.

Can you send (privately) readelf -a output from your vdso.so ? 
Your linker must be doing something weird.

0xc00 is quite wasteful.

-Andi

vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

[Andi Kleen]

On Monday 23 July 2007 01:38:40 Andre Noll wrote:
[readded linux-kernel, Linus]

>   [Nr] Name              Type             Address           Offset
>        Size              EntSize          Flags  Link  Info  Align
>   [ 0]                   NULL             0000000000000000  00000000
>        0000000000000000  0000000000000000           0     0     0
>   [ 1] .hash             HASH             ffffffffff700120  00000120
>        00000000000000b4  0000000000000004   A       2     0     8
>   [ 2] .dynsym           DYNSYM           ffffffffff7001d8  000001d8
>        0000000000000270  0000000000000018   A       3    12     8
>   [ 3] .dynstr           STRTAB           ffffffffff700448  00000448
>        0000000000000059  0000000000000000   A       0     0     1
>   [ 4] .gnu.version      VERSYM           ffffffffff7004a2  000004a2
>        0000000000000034  0000000000000002   A       2     0     2
>   [ 5] .gnu.version_d    VERDEF           ffffffffff7004d8  000004d8
>        0000000000000038  0000000000000000   A       3     2     8
>   [ 6] .text             PROGBITS         ffffffffff700c00  00100bab
                                                              ^^^^^^^^
>        00000000000002e4  0000000000000000  AX       0     0     64

It puts .text at 1MB. Your vdso file must be huge? 

It looks like it ignores the
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
options passed to it. The AMD64 ABI has a 1MB minimum page size, but
these options are supposed to disable it.

Not sure how to work around this, but having an 1+MB vdso would be incredibly
wasteful. What version is it? Perhaps we just drop support for this. I can't
think of a workaround currently.

-Andi

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

[Jakub Jelinek]

On Mon, Jul 23, 2007 at 01:56:20AM +0200, Andi Kleen wrote:
> On Monday 23 July 2007 01:38:40 Andre Noll wrote:
> [readded linux-kernel, Linus]
> 
> >   [Nr] Name              Type             Address           Offset
> >        Size              EntSize          Flags  Link  Info  Align
> >   [ 0]                   NULL             0000000000000000  00000000
> >        0000000000000000  0000000000000000           0     0     0
> >   [ 1] .hash             HASH             ffffffffff700120  00000120
> >        00000000000000b4  0000000000000004   A       2     0     8
> >   [ 2] .dynsym           DYNSYM           ffffffffff7001d8  000001d8
> >        0000000000000270  0000000000000018   A       3    12     8
> >   [ 3] .dynstr           STRTAB           ffffffffff700448  00000448
> >        0000000000000059  0000000000000000   A       0     0     1
> >   [ 4] .gnu.version      VERSYM           ffffffffff7004a2  000004a2
> >        0000000000000034  0000000000000002   A       2     0     2
> >   [ 5] .gnu.version_d    VERDEF           ffffffffff7004d8  000004d8
> >        0000000000000038  0000000000000000   A       3     2     8
> >   [ 6] .text             PROGBITS         ffffffffff700c00  00100bab
>                                                               ^^^^^^^^
> >        00000000000002e4  0000000000000000  AX       0     0     64
> 
> It puts .text at 1MB. Your vdso file must be huge? 
> 
> It looks like it ignores the
> -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
> options passed to it. The AMD64 ABI has a 1MB minimum page size, but
> these options are supposed to disable it.

These options are fairly new, before they were ignored (like all unknown
-z options).  They were added 2006-05-30 to CVS binutils.

I guess the problem is caused by the gap being too big and old binutils.

	Jakub

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

[Andi Kleen]

> These options are fairly new, before they were ignored (like all unknown
> -z options).  They were added 2006-05-30 to CVS binutils.
>
> I guess the problem is caused by the gap being too big and old binutils.

Can you think of a workaround Jakub? 

-Andi

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

[Jakub Jelinek]

On Mon, Jul 23, 2007 at 01:56:20AM +0200, Andi Kleen wrote:
> On Monday 23 July 2007 01:38:40 Andre Noll wrote:
> [readded linux-kernel, Linus]
> 
> >   [Nr] Name              Type             Address           Offset
> >        Size              EntSize          Flags  Link  Info  Align
> >   [ 0]                   NULL             0000000000000000  00000000
> >        0000000000000000  0000000000000000           0     0     0
> >   [ 1] .hash             HASH             ffffffffff700120  00000120
> >        00000000000000b4  0000000000000004   A       2     0     8
> >   [ 2] .dynsym           DYNSYM           ffffffffff7001d8  000001d8
> >        0000000000000270  0000000000000018   A       3    12     8
> >   [ 3] .dynstr           STRTAB           ffffffffff700448  00000448
> >        0000000000000059  0000000000000000   A       0     0     1
> >   [ 4] .gnu.version      VERSYM           ffffffffff7004a2  000004a2
> >        0000000000000034  0000000000000002   A       2     0     2
> >   [ 5] .gnu.version_d    VERDEF           ffffffffff7004d8  000004d8
> >        0000000000000038  0000000000000000   A       3     2     8
> >   [ 6] .text             PROGBITS         ffffffffff700c00  00100bab
>                                                               ^^^^^^^^
> >        00000000000002e4  0000000000000000  AX       0     0     64
> 
> It puts .text at 1MB. Your vdso file must be huge? 
> 
> It looks like it ignores the
> -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
> options passed to it. The AMD64 ABI has a 1MB minimum page size, but
> these options are supposed to disable it.
> 
> Not sure how to work around this, but having an 1+MB vdso would be incredibly
> wasteful. What version is it? Perhaps we just drop support for this. I can't
> think of a workaround currently.

Looking at vdso.lds.S, if you change just VDSO_TEXT_OFFSET to 0xc00 and
don't tweak the linker script, then you jump backwards with the dot, you
should even get a linker warning about it:

  . = VDSO_PRELINK + VDSO_TEXT_OFFSET;

  .text           : { *(.text) }                :text
  .text.ptr       : { *(.text.ptr) }            :text
  . = VDSO_PRELINK + 0x900;

Guess that 0x900 should have been VDSO_TEXT_OFFSET + 0x400 or something
similar.  Also note that it is highly desirable to fit the whole vdso into
one page, so increasing VDSO_TEXT_OFFSET etc. offsets too much is just
wasting memory.  From the above dump, VDSO_TEXT_OFFSET 0x500 is too low,
but 0x600 should work, assuming .data section is moved 0x100 higher as well.

	Jakub

Re: vdso.so mislinked by buggy linker was Re: Linus 2.6.23-rc1

[Andi Kleen]

> Looking at vdso.lds.S, if you change just VDSO_TEXT_OFFSET to 0xc00 and
> don't tweak the linker script, then you jump backwards with the dot, you
> should even get a linker warning about it:
> 
>   . = VDSO_PRELINK + VDSO_TEXT_OFFSET;
> 
>   .text           : { *(.text) }                :text
>   .text.ptr       : { *(.text.ptr) }            :text
>   . = VDSO_PRELINK + 0x900;
> 
> Guess that 0x900 should have been VDSO_TEXT_OFFSET + 0x400 or something
> similar.  Also note that it is highly desirable to fit the whole vdso into
> one page, so increasing VDSO_TEXT_OFFSET etc. offsets too much is just
> wasting memory.  From the above dump, VDSO_TEXT_OFFSET 0x500 is too low,
> but 0x600 should work, 

The reporter reported only 0xc00 worked, which is mysterious.

Also how do we get rid of the 1MB padding on those binutils? 

-Andi

Re: Linus 2.6.23-rc1

[Jakub Jelinek]

On Mon, Jul 23, 2007 at 01:31:00AM +0200, Andi Kleen wrote:
> On Monday 23 July 2007 01:23:38 Andre Noll wrote:
> > On 00:22, Andi Kleen wrote:
> > > > /usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
> > > 
> > > Does this patch fix it?
> > 
> > Nope, with 0x600 I still get the same error. But it helped to further
> > increase VDSO_TEXT_OFFSET to 0xc00. I tried 0x700, 0x800,... and 0xc00
> > is the smallest value in this series that makes the error go away, i.e.
> > the patch below works for me.
> 
> Can you send (privately) readelf -a output from your vdso.so ? 
> Your linker must be doing something weird.
> 
> 0xc00 is quite wasteful.

I think Roland's --build-id doesn't create very big section, the likely
culprit would be a hacked up ld that e.g. defaults to --hash-style=both.
Can you retry with --hash-style=sysv?  vdso really has to include the
traditional .hash section, otherwise it wouldn't be compatible with
old glibcs, and an additional .gnu.hash might be an overkill for it
- doesn't the vdso define only very few symbols?

	Jakub

Re: Linus 2.6.23-rc1

[Alistair John Strachan]

On Sunday 22 July 2007 22:04:24 Linus Torvalds wrote:
> So give it all a good whacking, and report back about all the neat new
> features!

I'm fairly sure this is already known about on SPARC64 (see David Miller's 
email ""build-id" changes break sparc64"), but I just thought I'd let people 
know the warnings are also visible on x86_64:

"ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored."

gcc (GCC) 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)
GNU assembler (GNU Binutils for Debian) 2.17.50.20070718

The kernel boots and works fine, however. The above tools are from Debian 
unstable.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

Re: Linus 2.6.23-rc1

[Roland McGrath]

> I'm fairly sure this is already known about on SPARC64 (see David Miller's 
> email ""build-id" changes break sparc64"), but I just thought I'd let people 
> know the warnings are also visible on x86_64:
> 
> "ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored."

I don't have any such problem using an ld built from current binutils cvs.

> GNU assembler (GNU Binutils for Debian) 2.17.50.20070718

This ld build, whatever it is, is suspect.  
I have no idea what code is in there.


Thanks,
Roland

Re: Linus 2.6.23-rc1

[Adrian Bunk]

On Sun, Jul 22, 2007 at 04:51:30PM -0700, Roland McGrath wrote:
> > I'm fairly sure this is already known about on SPARC64 (see David Miller's 
> > email ""build-id" changes break sparc64"), but I just thought I'd let people 
> > know the warnings are also visible on x86_64:
> > 
> > "ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored."
> 
> I don't have any such problem using an ld built from current binutils cvs.
> 
> > GNU assembler (GNU Binutils for Debian) 2.17.50.20070718
> 
> This ld build, whatever it is, is suspect.  
> I have no idea what code is in there.

That's the Debian unstable package of binutils containing what was on 
20070718 in the upstream binutils CVS (the version number comes from 
the upstream CVS).

> Thanks,
> Roland

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linus 2.6.23-rc1

[Roland McGrath]

> That's the Debian unstable package of binutils containing what was on 
> 20070718 in the upstream binutils CVS (the version number comes from 
> the upstream CVS).

At what time on July 18?  Before or after the commits I made that day?
You see, I can't tell from the information at hand.

Re: Linus 2.6.23-rc1

[Adrian Bunk]

On Sun, Jul 22, 2007 at 05:31:03PM -0700, Roland McGrath wrote:
> > That's the Debian unstable package of binutils containing what was on 
> > 20070718 in the upstream binutils CVS (the version number comes from 
> > the upstream CVS).
> 
> At what time on July 18?  Before or after the commits I made that day?

ld/ChangeLog contains your entry for this day.

> You see, I can't tell from the information at hand.

The information comes directly from bfd/version.h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linus 2.6.23-rc1

[Gabriel C]

Linus Torvalds wrote:
> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 

allmodconfig is broken

...

drivers/misc/asus-laptop.c: In function 'asus_led_exit':
drivers/misc/asus-laptop.c:1076: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1076: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1077: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1077: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1078: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1078: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1079: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1079: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1080: error: 'struct led_classdev' has no member named 'class_dev'
drivers/misc/asus-laptop.c:1080: error: 'struct led_classdev' has no member named 'class_dev'
make[2]: *** [drivers/misc/asus-laptop.o] Error 1
make[2]: *** Waiting for unfinished jobs....


...


Regards,

Gabriel C

Re: Linus 2.6.23-rc1

[Paul Mundt]

On Sun, Jul 22, 2007 at 02:04:24PM -0700, Linus Torvalds wrote:
> Lots of architecture updates (for just about all of them - x86[-64], arm, 
> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
> (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
> firewire, i2c, you name it).
> 
Some of the driver model changes that went in result in a link error:

  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
drivers/built-in.o: In function `store_uevent':
: undefined reference to `kobject_actions'
make: *** [.tmp_vmlinux1] Error 1

Haven't bisected it yet, but I suppose it's pretty obvious to whoever made the
changes. ;-)

.config follows:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 10:02:46 2007
#
CONFIG_SUPERH=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

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

#
# System type
#
CONFIG_CPU_SH4=y
# CONFIG_CPU_SUBTYPE_SH7619 is not set
# CONFIG_CPU_SUBTYPE_SH7206 is not set
# CONFIG_CPU_SUBTYPE_SH7300 is not set
# CONFIG_CPU_SUBTYPE_SH7705 is not set
# CONFIG_CPU_SUBTYPE_SH7706 is not set
# CONFIG_CPU_SUBTYPE_SH7707 is not set
# CONFIG_CPU_SUBTYPE_SH7708 is not set
# CONFIG_CPU_SUBTYPE_SH7709 is not set
# CONFIG_CPU_SUBTYPE_SH7710 is not set
# CONFIG_CPU_SUBTYPE_SH7712 is not set
CONFIG_CPU_SUBTYPE_SH7750=y
# CONFIG_CPU_SUBTYPE_SH7091 is not set
# CONFIG_CPU_SUBTYPE_SH7750R is not set
# CONFIG_CPU_SUBTYPE_SH7750S is not set
# CONFIG_CPU_SUBTYPE_SH7751 is not set
# CONFIG_CPU_SUBTYPE_SH7751R is not set
# CONFIG_CPU_SUBTYPE_SH7760 is not set
# CONFIG_CPU_SUBTYPE_SH4_202 is not set
# CONFIG_CPU_SUBTYPE_ST40STB1 is not set
# CONFIG_CPU_SUBTYPE_ST40GX1 is not set
# CONFIG_CPU_SUBTYPE_SH7770 is not set
# CONFIG_CPU_SUBTYPE_SH7780 is not set
# CONFIG_CPU_SUBTYPE_SH7785 is not set
# CONFIG_CPU_SUBTYPE_SHX3 is not set
# CONFIG_CPU_SUBTYPE_SH73180 is not set
# CONFIG_CPU_SUBTYPE_SH7343 is not set
# CONFIG_CPU_SUBTYPE_SH7722 is not set

#
# Memory management options
#
CONFIG_QUICKLIST=y
CONFIG_MMU=y
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_MEMORY_START=0x0c000000
CONFIG_MEMORY_SIZE=0x02000000
CONFIG_VSYSCALL=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_MAX_ACTIVE_REGIONS=1
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_NR_QUICK=2
CONFIG_VIRT_TO_BUS=y

#
# Cache configuration
#
# CONFIG_SH_DIRECT_MAPPED is not set
# CONFIG_SH_WRITETHROUGH is not set

#
# Processor features
#
CONFIG_CPU_LITTLE_ENDIAN=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_SH_FPU=y
# CONFIG_SH_DSP is not set
# CONFIG_SH_STORE_QUEUES is not set
CONFIG_CPU_HAS_INTEVT=y
CONFIG_CPU_HAS_INTC_IRQ=y
CONFIG_CPU_HAS_IPR_IRQ=y
CONFIG_CPU_HAS_SR_RB=y
CONFIG_CPU_HAS_PTEA=y

#
# Board support
#
CONFIG_SOLUTION_ENGINE=y
CONFIG_SH_SOLUTION_ENGINE=y

#
# Timer and clock configuration
#
CONFIG_SH_TMU=y
CONFIG_SH_TIMER_IRQ=16
CONFIG_SH_PCLK_FREQ=33333333
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# DMA support
#
# CONFIG_SH_DMA is not set

#
# Companion Chips
#

#
# Additional SuperH Device Drivers
#
CONFIG_HEARTBEAT=y
# CONFIG_PUSH_SWITCH is not set

#
# Kernel features
#
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# Boot options
#
CONFIG_ZERO_PAGE_OFFSET=0x00001000
CONFIG_BOOT_LINK_OFFSET=0x00800000
# CONFIG_UBC_WAKEUP is not set
# CONFIG_CMDLINE_BOOL is not set

#
# Bus options
#
CONFIG_CF_ENABLER=y
# CONFIG_CF_AREA5 is not set
CONFIG_CF_AREA6=y
CONFIG_CF_BASE_ADDR=0xb8000000
# CONFIG_ARCH_SUPPORTS_MSI is not set

#
# PCCARD (PCMCIA/CardBus) support
#

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP 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_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

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

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
CONFIG_MTD_ROM=y
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_DEVICES=y
# CONFIG_EEPROM_93CX6 is not set
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y

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

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_IDEPCI_PCIBUS_ORDER is not set
# CONFIG_IDE_ARM is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_BLK_DEV_HD is not set

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

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# 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 is not set
# CONFIG_CHR_DEV_SCH is not set

#
# 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
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
CONFIG_STNIC=y
# CONFIG_SMC91X is not set
CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=2
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_SH_WDT=y
# CONFIG_SH_WDT_MMAP is not set
CONFIG_HW_RANDOM=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y

#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_USB_SUPPORT=y
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set

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

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4DEV_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN 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=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_SH_STANDARD_BIOS is not set
# CONFIG_EARLY_SCIF_CONSOLE is not set
# CONFIG_SH_KGDB is not set

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

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y

Re: Linus 2.6.23-rc1

[Gabriel C]

Paul Mundt wrote:
> On Sun, Jul 22, 2007 at 02:04:24PM -0700, Linus Torvalds wrote:
>> Lots of architecture updates (for just about all of them - x86[-64], arm, 
>> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
>> (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
>> firewire, i2c, you name it).
>>
> Some of the driver model changes that went in result in a link error:
> 
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> drivers/built-in.o: In function `store_uevent':
> : undefined reference to `kobject_actions'
> make: *** [.tmp_vmlinux1] Error 1
> 
> Haven't bisected it yet, but I suppose it's pretty obvious to whoever made the
> changes. ;-)

CONFIG_HOTPLUG=n :)

Try this patch :
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver/kobject-fix-link-error-when-config_hotplug-is-disabled.patch



Regards,

Gabriel

Re: Linus 2.6.23-rc1

[Paul Mundt]

On Mon, Jul 23, 2007 at 03:27:21AM +0200, Gabriel C wrote:
> Paul Mundt wrote:
> > On Sun, Jul 22, 2007 at 02:04:24PM -0700, Linus Torvalds wrote:
> >> Lots of architecture updates (for just about all of them - x86[-64], arm, 
> >> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
> >> (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
> >> firewire, i2c, you name it).
> >>
> > Some of the driver model changes that went in result in a link error:
> > 
> >   CC      init/version.o
> >   LD      init/built-in.o
> >   LD      .tmp_vmlinux1
> > drivers/built-in.o: In function `store_uevent':
> > : undefined reference to `kobject_actions'
> > make: *** [.tmp_vmlinux1] Error 1
> > 
> > Haven't bisected it yet, but I suppose it's pretty obvious to whoever made the
> > changes. ;-)
> 
> CONFIG_HOTPLUG=n :)
> 
> Try this patch :
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver/kobject-fix-link-error-when-config_hotplug-is-disabled.patch
> 
Yup, that fixes it. I'll just enable it across the defconfigs for now, thanks.

Re: Linus 2.6.23-rc1

[Greg KH]

On Mon, Jul 23, 2007 at 10:23:17AM +0900, Paul Mundt wrote:
> On Sun, Jul 22, 2007 at 02:04:24PM -0700, Linus Torvalds wrote:
> > Lots of architecture updates (for just about all of them - x86[-64], arm, 
> > alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
> > (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
> > firewire, i2c, you name it).
> > 
> Some of the driver model changes that went in result in a link error:
> 
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> drivers/built-in.o: In function `store_uevent':
> : undefined reference to `kobject_actions'
> make: *** [.tmp_vmlinux1] Error 1
> 
> Haven't bisected it yet, but I suppose it's pretty obvious to whoever
> made the changes. ;-)

Yes, the patch is on the list (and been pointed out already) and is in
my queue to send to Linus in the next few days.

thanks,

greg k-h

Re: Linus 2.6.23-rc1

[Gabriel C]

allyesconfig has a lot 'Section mismatch' warnings 


...


  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x183): Section mismatch: reference to .init.text.1:start_kernel (between 'is386' and 'check_x87')
WARNING: vmlinux.o(.data+0x4b38): Section mismatch: reference to .init.text.3:powernow_cpu_init (between 'powernow_driver' and 'minimum_speed')
WARNING: vmlinux.o(.data+0x4c2c): Section mismatch: reference to .init.text.3:longhaul_cpu_init (between 'longhaul_driver' and 'numscales')
WARNING: vmlinux.o(.data+0x4cf4): Section mismatch: reference to .init.text.3:longrun_cpu_init (between 'longrun_driver' and 'max_duration')
WARNING: vmlinux.o(.data+0x57f4): Section mismatch: reference to .init.text.3:native_smp_prepare_boot_cpu (between 'smp_ops' and 'call_lock')
WARNING: vmlinux.o(.data+0x57f8): Section mismatch: reference to .init.text.3:native_smp_prepare_cpus (between 'smp_ops' and 'call_lock')
WARNING: vmlinux.o(.data+0x5800): Section mismatch: reference to .init.text.3:native_smp_cpus_done (between 'smp_ops' and 'call_lock')
WARNING: vmlinux.o(.data+0x6c00): Section mismatch: reference to .init.text.5:machine_specific_memory_setup (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6c08): Section mismatch: reference to .init.text.3:native_init_IRQ (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6c0c): Section mismatch: reference to .init.text.3:hpet_time_init (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6c10): Section mismatch: reference to .init.text.4:native_pagetable_setup_start (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6c14): Section mismatch: reference to .init.text.4:native_pagetable_setup_done (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6c18): Section mismatch: reference to .init.text.3:default_banner (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x6cdc): Section mismatch: reference to .init.text.3:setup_boot_APIC_clock (between 'paravirt_ops' and 'reserve_ioports')
WARNING: vmlinux.o(.data+0x9b43c): Section mismatch: reference to .init.text.19:arcfb_probe (between 'arcfb_driver' and 'arcfb_ops')
WARNING: vmlinux.o(.data+0xa0950): Section mismatch: reference to .init.text.19:gx1fb_probe (between 'gx1fb_driver' and 'gx1fb_ops')
WARNING: vmlinux.o(.data+0xa0b98): Section mismatch: reference to .init.text.19:gxfb_probe (between 'gxfb_driver' and 'gxfb_ops')
WARNING: vmlinux.o(.data+0xa2c58): Section mismatch: reference to .init.text.19:hgafb_probe (between 'hgafb_driver' and 'hgafb_device')
WARNING: vmlinux.o(.data+0xa3798): Section mismatch: reference to .init.text.19:sm501fb_probe (between 'sm501fb_driver' and 'dev_attr_fbregs_crt')
WARNING: vmlinux.o(.data+0xa39e4): Section mismatch: reference to .init.text.19:vesafb_probe (between 'vesafb_driver' and 'vesafb_ops')
WARNING: vmlinux.o(.data+0xa3b50): Section mismatch: reference to .init.text.19:imacfb_probe (between 'imacfb_driver' and 'imacfb_device')
WARNING: vmlinux.o(.data+0xa3ed4): Section mismatch: reference to .init.text.19:vga16fb_probe (between 'vga16fb_driver' and 'vga16fb_ops')
WARNING: vmlinux.o(.data+0xa4040): Section mismatch: reference to .init.text.19:vfb_probe (between 'vfb_driver' and 'vfb_ops')
WARNING: vmlinux.o(.data+0xaf038): Section mismatch: reference to .init.text.19:hvc_console_setup (between 'hvc_con_driver' and 'vtermnos')
WARNING: vmlinux.o(.data+0xc22e0): Section mismatch: reference to .init.text.19:serial8250_console_setup (between 'serial8250_console' and 'serial8250_reg')
WARNING: vmlinux.o(.data+0xc22e4): Section mismatch: reference to .init.text.19:serial8250_console_early_setup (between 'serial8250_console' and 'serial8250_reg')
WARNING: vmlinux.o(.data+0xc9fb0): Section mismatch: reference to .init.text.19:cpqarray_init_one (between 'cpqarray_pci_driver' and 'ida_fops')
WARNING: vmlinux.o(.data+0xd7b38): Section mismatch: reference to .init.text.19:dgrs_eisa_probe (between 'dgrs_eisa_driver' and 'dgrs_pci_driver')
WARNING: vmlinux.o(.data+0xd7b5c): Section mismatch: reference to .init.text.19:dgrs_pci_probe (between 'dgrs_pci_driver' and '__param_str_nicmode')
WARNING: vmlinux.o(.data+0xd83c8): Section mismatch: reference to .init.text.19:vortex_eisa_probe (between 'vortex_eisa_driver' and '__param_str_use_mmio')
WARNING: vmlinux.o(.data+0x10ea34): Section mismatch: reference to .init.text.19:hp100_eisa_probe (between 'hp100_eisa_driver' and 'hp100_pci_driver')
WARNING: vmlinux.o(.data+0x10eee8): Section mismatch: reference to .init.text.19:ultramca_probe (between 'ultra_driver' and '__param_str_ultra_irq')
WARNING: vmlinux.o(.data+0x10f048): Section mismatch: reference to .init.text.19:ne3210_eisa_probe (between 'ne3210_eisa_driver' and 'ne3210_ids')
WARNING: vmlinux.o(.data+0x110f14): Section mismatch: reference to .init.text.19:el3_eisa_probe (between 'el3_eisa_driver' and 'el3_mca_driver')
WARNING: vmlinux.o(.data+0x111010): Section mismatch: reference to .init.text.19:el3_mca_probe (between 'el3_mca_driver' and '__param_str_nopnp')
WARNING: vmlinux.o(.data+0x111af4): Section mismatch: reference to .init.text.19:depca_mca_probe (between 'depca_mca_driver' and 'depca_eisa_driver')
WARNING: vmlinux.o(.data+0x111be8): Section mismatch: reference to .init.text.19:depca_eisa_probe (between 'depca_eisa_driver' and 'depca_isa_driver')
WARNING: vmlinux.o(.data+0x111bfc): Section mismatch: reference to .init.text.19:depca_isa_probe (between 'depca_isa_driver' and 'depca_string')
WARNING: vmlinux.o(.data+0x12f4fc): Section mismatch: reference to .init.text.19:de4x5_eisa_probe (between 'de4x5_eisa_driver' and 'version')
WARNING: vmlinux.o(.data+0x13328c): Section mismatch: reference to .init.text.19:smsc_ircc_pnp_probe (between 'smsc_ircc_pnp_driver' and '__param_str_ircc_transceiver')
WARNING: vmlinux.o(.data+0x1a4360): Section mismatch: reference to .init.text.19:sim710_mca_probe (between 'sim710_mca_driver' and 'sim710_eisa_driver')
WARNING: vmlinux.o(.data+0x1a4454): Section mismatch: reference to .init.text.19:sim710_eisa_probe (between 'sim710_eisa_driver' and 'sim710_mca_id_table')
WARNING: vmlinux.o(.data+0x1a454c): Section mismatch: reference to .init.text.19:advansys_detect (between 'driver_template' and '_asc_mcode_buf')
WARNING: vmlinux.o(.data+0x1a58f8): Section mismatch: reference to .init.text.19:aha1542_detect (between 'driver_template' and 'aha1542_lock')
WARNING: vmlinux.o(.data+0x1b0564): Section mismatch: reference to .init.text.19:in2000_detect (between 'driver_template' and 'setup_args')
WARNING: vmlinux.o(.data+0x1b0634): Section mismatch: reference to .init.text.19:generic_NCR5380_detect (between 'driver_template' and '__param_str_dtc_3181e')
WARNING: vmlinux.o(.data+0x1b075c): Section mismatch: reference to .init.text.19:generic_NCR5380_detect (between 'driver_template' and '__param_str_dtc_3181e')
WARNING: vmlinux.o(.data+0x1b08ac): Section mismatch: reference to .init.text.19:NCR53c406a_detect (between 'driver_template' and 'NCR_D700_driver')
WARNING: vmlinux.o(.data+0x1b0be0): Section mismatch: reference to .init.text.19:NCR_Q720_probe (between 'NCR_Q720_driver' and 'banner.22029')
WARNING: vmlinux.o(.data+0x1b0e98): Section mismatch: reference to .init.text.19:sym53c416_detect (between 'driver_template' and 'sym53c416_lock')
WARNING: vmlinux.o(.data+0x1c9de4): Section mismatch: reference to .init.text.19:pas16_detect (between 'driver_template' and 'irq')
WARNING: vmlinux.o(.data+0x1c9e7c): Section mismatch: reference to .init.text.19:seagate_st0x_detect (between 'driver_template' and 'hostno')
WARNING: vmlinux.o(.data+0x1c9f50): Section mismatch: reference to .init.text.19:t128_detect (between 'driver_template' and 'dmx3191d_pci_driver')
WARNING: vmlinux.o(.data+0x1ca1fc): Section mismatch: reference to .init.text.19:dtc_detect (between 'driver_template' and 'sym_fw2')
WARNING: vmlinux.o(.data+0x1ccd60): Section mismatch: reference to .init.text.19:wd7000_detect (between 'driver_template' and 'freescbs')
WARNING: vmlinux.o(.data+0x1ce4ec): Section mismatch: reference to .init.text.19:gdth_detect (between 'driver_template' and 'gdth_notifier')
WARNING: vmlinux.o(.data+0x1e1e20): Section mismatch: reference to .init.text.19:cfag12864bfb_probe (between 'cfag12864bfb_driver' and 'cfag12864bfb_ops')
WARNING: vmlinux.o(.data+0x1e4f34): Section mismatch: reference to .init.text.19:plat_nand_probe (between 'plat_nand_driver' and 'onenand_oob_64')
WARNING: vmlinux.o(.data+0x1e8450): Section mismatch: reference to .init.text.19:cpu_has_kvm_support (between 'vmx_arch_ops' and 'kvm_vmx_segment_fields')
WARNING: vmlinux.o(.data+0x1e8454): Section mismatch: reference to .init.text.19:vmx_disabled_by_bios (between 'vmx_arch_ops' and 'kvm_vmx_segment_fields')
WARNING: vmlinux.o(.data+0x1e8460): Section mismatch: reference to .init.text.19:hardware_setup (between 'vmx_arch_ops' and 'kvm_vmx_segment_fields')
WARNING: vmlinux.o(.data+0x1e8584): Section mismatch: reference to .init.text.19:svm_hardware_setup (between 'svm_arch_ops' and 'aoe_bdops')
WARNING: vmlinux.o(.data+0x1eb3ac): Section mismatch: reference to .init.text.19:r8a66597_probe (between 'r8a66597_driver' and 'r8a66597_hc_driver')
WARNING: vmlinux.o(.data+0x27b49c): Section mismatch: reference to .init.text.19:stk17ta8_rtc_probe (between 'stk17ta8_rtc_driver' and 'stk17ta8_nvram_attr')
WARNING: vmlinux.o(.data+0x2a913c): Section mismatch: reference to .init.text.19:pci_eisa_init (between 'pci_eisa_driver' and 'pci_eisa_pci_tbl')

...


...

 Building modules, stage 2.
  CC      arch/i386/boot/a20.o
  CC      arch/i386/boot/apm.o
  CC      arch/i386/boot/cmdline.o
  MODPOST 13 modules
WARNING: vmlinux(.text+0xc0101183): Section mismatch: reference to .init.text:start_kernel (between 'is386' and 'check_x87')
WARNING: vmlinux(.text+0xc139103b): Section mismatch: reference to .init.text:kernel_init (between 'rest_init' and 'kthreadd_setup')
WARNING: vmlinux(.text+0xc13971fb): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc1397207): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc1397213): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc139721f): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc1391104): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'alloc_node_mem_map' and 'zone_wait_table_init')
WARNING: vmlinux(.text+0xc13911ad): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'zone_wait_table_init' and 'vgacon_scrollback_startup')
  AS      arch/i386/boot/copy.o
  CC      arch/i386/boot/cpu.o
  CC      arch/i386/boot/cpucheck.o
  CC      arch/i386/boot/edd.o
  AS      arch/i386/boot/header.o
  CC      arch/i386/boot/main.o
  CC      arch/i386/boot/mca.o
  CC      arch/i386/boot/memory.o
  CC      arch/i386/boot/pm.o
  AS      arch/i386/boot/pmjump.o
WARNING: vmlinux(.text+0xc1397843): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')
WARNING: vmlinux(.text+0xc1391201): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_scrollback_startup' and 'fb_find_logo')
WARNING: vmlinux(.text+0xc1391225): Section mismatch: reference to .init.data:logo_linux_mono (between 'fb_find_logo' and '__sched_text_start')
  CC      arch/i386/boot/printf.o
WARNING: vmlinux(.text+0xc139122f): Section mismatch: reference to .init.data:logo_linux_clut224 (between 'fb_find_logo' and '__sched_text_start')
WARNING: vmlinux(.text+0xc1391234): Section mismatch: reference to .init.data:logo_linux_vga16 (between 'fb_find_logo' and '__sched_text_start')
  CC      arch/i386/boot/string.o
  CC      arch/i386/boot/tty.o
WARNING: vmlinux(.text+0xc1397b60): Section mismatch: reference to .init.text: (between 'iret_exc' and '_etext')

...


Regards,

Gabriel C

alpha, i386,mips,powerpc,ppc,xtensa compile brakage (was Re: Linus 2.6.23-rc1)

[Jan Dittmer]

Linus Torvalds wrote:
> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.

Compared to 2.6.22>

# alpha/defconfig: broke

   LD      .tmp_vmlinux1
arch/alpha/kernel/built-in.o(.text+0xcdf8): In function `module_frob_arch_sections':
include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large'
arch/alpha/kernel/built-in.o(.text+0xcdfc):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large'
arch/alpha/kernel/built-in.o(.text+0x190d8): In function `srmcons_get_private_struct':
include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large'
arch/alpha/kernel/built-in.o(.text+0x190dc):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large'
arch/alpha/kernel/built-in.o(.init.text+0x948): In function `register_cpus':
include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large'
arch/alpha/kernel/built-in.o(.init.text+0x94c):include/linux/slub_def.h:154: more undefined references to `__kmalloc_size_too_large' follow
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

# i386/allmodconfig: broke

   CC [M]  drivers/misc/asus-laptop.o
drivers/misc/asus-laptop.c: In function `asus_led_exit':
drivers/misc/asus-laptop.c:1076: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1076: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1077: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1077: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1078: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1078: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1079: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1079: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1080: error: structure has no member named `class_dev'
drivers/misc/asus-laptop.c:1080: error: structure has no member named `class_dev'
make[3]: *** [drivers/misc/asus-laptop.o] Error 1
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2

# mips/defconfig: broke

   GEN     .version
   CHK     include/linux/compile.h
   UPD     include/linux/compile.h
   CC      init/version.o
   LD      init/built-in.o
   LD      .tmp_vmlinux1
drivers/built-in.o(.text+0x1ce30): In function `store_uevent':
drivers/base/core.c: undefined reference to `kobject_actions'
drivers/built-in.o(.text+0x1ce34):drivers/base/core.c: undefined reference to `kobject_actions'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

# powerpc/iseries_defconfig: broke

   CC [M]  drivers/scsi/scsi_transport_sas.o
   CC [M]  drivers/scsi/scsi_wait_scan.o
   LD      drivers/scsi/ibmvscsi/built-in.o
   CC [M]  drivers/scsi/ibmvscsi/ibmvscsi.o
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_reset_host':
drivers/scsi/ibmvscsi/ibmvscsi.c:517: error: implicit declaration of function 'vio_enable_interrupts'
make[4]: *** [drivers/scsi/ibmvscsi/ibmvscsi.o] Error 1
make[3]: *** [drivers/scsi/ibmvscsi] Error 2
make[2]: *** [drivers/scsi] Error 2
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2

# ppc/bamboo_defconfig: broke

   GEN     .version
   CHK     include/linux/compile.h
   UPD     include/linux/compile.h
   CC      init/version.o
   LD      init/built-in.o
   LD      .tmp_vmlinux1
drivers/built-in.o(.text+0x1ebda): In function `store_uevent':
drivers/base/core.c:312: undefined reference to `kobject_actions'
drivers/built-in.o(.text+0x1ebe6):drivers/base/core.c:312: undefined reference to `kobject_actions'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

# xtensa/defconfig: broke
   CC      kernel/time/clocksource.o
In file included from include/linux/clocksource.h:18,
                  from kernel/time/clocksource.c:27:
include2/asm/io.h: In function `virt_to_phys':
include2/asm/io.h:46: error: implicit declaration of function `__pa'
include2/asm/io.h: In function `phys_to_virt':
include2/asm/io.h:51: error: implicit declaration of function `__va'
include2/asm/io.h:51: warning: return makes pointer from integer without a cast
make[3]: *** [kernel/time/clocksource.o] Error 1
make[2]: *** [kernel/time] Error 2
make[1]: *** [kernel] Error 2
make: *** [_all] Error 2

Jan

Re: alpha, i386,mips,powerpc,ppc,xtensa compile brakage (was Re: Linus 2.6.23-rc1)

[Stephen Rothwell]

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

On Mon, 23 Jul 2007 09:14:12 +0200 Jan Dittmer <jdi@l4x.org> wrote:
>
> # powerpc/iseries_defconfig: broke
> 
>    CC [M]  drivers/scsi/scsi_transport_sas.o
>    CC [M]  drivers/scsi/scsi_wait_scan.o
>    LD      drivers/scsi/ibmvscsi/built-in.o
>    CC [M]  drivers/scsi/ibmvscsi/ibmvscsi.o
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_reset_host':
> drivers/scsi/ibmvscsi/ibmvscsi.c:517: error: implicit declaration of function 'vio_enable_interrupts'

Patch sent to Paulus today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: alpha, i386,mips,powerpc,ppc,xtensa compile brakage (was Re: Linus 2.6.23-rc1)

[Josh Boyer]

On 7/23/07, Jan Dittmer <jdi@l4x.org> wrote:
> # ppc/bamboo_defconfig: broke
>
>    GEN     .version
>    CHK     include/linux/compile.h
>    UPD     include/linux/compile.h
>    CC      init/version.o
>    LD      init/built-in.o
>    LD      .tmp_vmlinux1
> drivers/built-in.o(.text+0x1ebda): In function `store_uevent':
> drivers/base/core.c:312: undefined reference to `kobject_actions'
> drivers/built-in.o(.text+0x1ebe6):drivers/base/core.c:312: undefined reference to `kobject_actions'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [_all] Error 2

This is the HOTPLUG one that GregKH knows about and has a patch for I
think.  Not PPC specific.

josh

Re: alpha, i386,mips,powerpc,ppc,xtensa compile brakage (was Re: Linus 2.6.23-rc1)

[Gabriel C]

Josh Boyer wrote:
> On 7/23/07, Jan Dittmer <jdi@l4x.org> wrote:
>> # ppc/bamboo_defconfig: broke
>>
>>    GEN     .version
>>    CHK     include/linux/compile.h
>>    UPD     include/linux/compile.h
>>    CC      init/version.o
>>    LD      init/built-in.o
>>    LD      .tmp_vmlinux1
>> drivers/built-in.o(.text+0x1ebda): In function `store_uevent':
>> drivers/base/core.c:312: undefined reference to `kobject_actions'
>> drivers/built-in.o(.text+0x1ebe6):drivers/base/core.c:312: undefined reference to `kobject_actions'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [_all] Error 2
> 
> This is the HOTPLUG one that GregKH knows about and has a patch for I
> think.  Not PPC specific.

Yes CONFIG_HOTPLUG=n 

See http://lkml.org/lkml/2007/7/22/303 , there is an link to the patch.


> 
> josh

Regards,

Gabriel C

Re: Linus 2.6.23-rc1: ACPI-related oops on x86_64

[Mel Gorman]

On (22/07/07 14:04), Linus Torvalds didst pronounce:
> 
> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 

This was seen on a machine on test.kernel.org;

Unable to handle kernel NULL pointer dereference at 0000000000000000
RIP: 
 [<ffffffff8037379b>] acpi_processor_throttling_seq_show+0xa7/0xd6
PGD 3bd9e067 PUD 3bc6a067 PMD 0 
Oops: 0000 [1] SMP 
CPU 3 
Modules linked in: video output button battery floppy ac lp parport_pc
parport nvram amd_rng rng_core i2c_amd756 i2c_core
Pid: 1522, comm: head Not tainted 2.6.23-rc1-autokern1 #1
RIP: 0010:[<ffffffff8037379b>]  [<ffffffff8037379b>]
acpi_processor_throttling_seq_show+0xa7/0xd6
RSP: 0018:ffff81003c4a5e48  EFLAGS: 00010246
RAX: 0000000000000020 RBX: ffff810037ea1800 RCX: 0000000000000000
RDX: 000000000000002a RSI: ffffffff80599c02 RDI: ffff810037c6a9c0
RBP: ffff810037c6a9c0 R08: ffff81003c3e3051 R09: ffff810037c6a9c0
R10: ffffffffffffffff R11: ffffffff80373e66 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 00007fffd59dcd40
FS:  00002b7ad50e36f0(0000) GS:ffff81003ee56b40(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000003bd9b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process head (pid: 1522, threadinfo ffff81003c4a4000, task ffff81003ee81040)
Stack:  ffff81003eed7180 ffff810037c6a9c0 0000000000000001 0000000000000001
 0000000000002000 ffffffff802a77b3 ffff81003c4a5f50 ffff81003e2f8ec0
 ffff810037c6a9f0 ffff81003de65000 0000000000000000 fffffffffffffffb
Call Trace:
 [<ffffffff802a77b3>] seq_read+0x105/0x28e
 [<ffffffff802a76ae>] seq_read+0x0/0x28e
 [<ffffffff802c8501>] proc_reg_read+0x80/0x9a
 [<ffffffff8028eb3d>] vfs_read+0xcb/0x153
 [<ffffffff8028eed9>] sys_read+0x45/0x6e
 [<ffffffff8020bc6e>] system_call+0x7e/0x83
FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.23-rc1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
No such device

Full oops is at http://test.kernel.org/abat/100837/debug/console.log
Config file at http://test.kernel.org/abat/100837/build/dotconfig

People are added to the CC that git shows were in this general area
recently in case they have the quick answer.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: Linus 2.6.23-rc1: ACPI-related oops on x86_64

[Len Brown]

On Monday 23 July 2007 05:50, Mel Gorman wrote:

> This was seen on a machine on test.kernel.org;
> 
> Unable to handle kernel NULL pointer dereference at 0000000000000000
> RIP: 
>  [<ffffffff8037379b>] acpi_processor_throttling_seq_show+0xa7/0xd6
> PGD 3bd9e067 PUD 3bc6a067 PMD 0 
> Oops: 0000 [1] SMP 
> CPU 3 
> Modules linked in: video output button battery floppy ac lp parport_pc
> parport nvram amd_rng rng_core i2c_amd756 i2c_core
> Pid: 1522, comm: head Not tainted 2.6.23-rc1-autokern1 #1
> RIP: 0010:[<ffffffff8037379b>]  [<ffffffff8037379b>]
> acpi_processor_throttling_seq_show+0xa7/0xd6
> RSP: 0018:ffff81003c4a5e48  EFLAGS: 00010246
> RAX: 0000000000000020 RBX: ffff810037ea1800 RCX: 0000000000000000
> RDX: 000000000000002a RSI: ffffffff80599c02 RDI: ffff810037c6a9c0
> RBP: ffff810037c6a9c0 R08: ffff81003c3e3051 R09: ffff810037c6a9c0
> R10: ffffffffffffffff R11: ffffffff80373e66 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 00007fffd59dcd40
> FS:  00002b7ad50e36f0(0000) GS:ffff81003ee56b40(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 000000003bd9b000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process head (pid: 1522, threadinfo ffff81003c4a4000, task ffff81003ee81040)
> Stack:  ffff81003eed7180 ffff810037c6a9c0 0000000000000001 0000000000000001
>  0000000000002000 ffffffff802a77b3 ffff81003c4a5f50 ffff81003e2f8ec0
>  ffff810037c6a9f0 ffff81003de65000 0000000000000000 fffffffffffffffb
> Call Trace:
>  [<ffffffff802a77b3>] seq_read+0x105/0x28e
>  [<ffffffff802a76ae>] seq_read+0x0/0x28e
>  [<ffffffff802c8501>] proc_reg_read+0x80/0x9a
>  [<ffffffff8028eb3d>] vfs_read+0xcb/0x153
>  [<ffffffff8028eed9>] sys_read+0x45/0x6e
>  [<ffffffff8020bc6e>] system_call+0x7e/0x83
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.23-rc1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
> No such device
> 
> Full oops is at http://test.kernel.org/abat/100837/debug/console.log
> Config file at http://test.kernel.org/abat/100837/build/dotconfig

try this,
thanks,
-Len

Subject: fix oops due to typo in new throttling code
From: Luming Yu <luming.yu@gmail.com>


Signed-off-by: Luming Yu <luming.yu@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>

---

 drivers/acpi/processor_throttling.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

Index: linus/drivers/acpi/processor_throttling.c
===================================================================
--- linus.orig/drivers/acpi/processor_throttling.c
+++ linus/drivers/acpi/processor_throttling.c
@@ -658,18 +658,20 @@ static int acpi_processor_throttling_seq
 		   pr->throttling.state_count - 1);
 
 	seq_puts(seq, "states:\n");
-	if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
+	if (pr->throttling.acpi_processor_get_throttling ==
+			acpi_processor_get_throttling_fadt) {
 		for (i = 0; i < pr->throttling.state_count; i++)
 			seq_printf(seq, "   %cT%d:                  %02d%%\n",
 				   (i == pr->throttling.state ? '*' : ' '), i,
 				   (pr->throttling.states[i].performance ? pr->
 				    throttling.states[i].performance / 10 : 0));
-	else
+	} else {
 		for (i = 0; i < pr->throttling.state_count; i++)
 			seq_printf(seq, "   %cT%d:                  %02d%%\n",
 				   (i == pr->throttling.state ? '*' : ' '), i,
 				   (int)pr->throttling.states_tss[i].
 				   freqpercentage);
+	}
 
       end:
 	return 0;

Re: Linus 2.6.23-rc1: ACPI-related oops on x86_64

[Mel Gorman]

On Mon, 23 Jul 2007, Len Brown wrote:

> On Monday 23 July 2007 05:50, Mel Gorman wrote:
>
>> This was seen on a machine on test.kernel.org;
>>
>> Unable to handle kernel NULL pointer dereference at 0000000000000000
>> RIP:
>>  [<ffffffff8037379b>] acpi_processor_throttling_seq_show+0xa7/0xd6
>> PGD 3bd9e067 PUD 3bc6a067 PMD 0
>> Oops: 0000 [1] SMP
>> CPU 3
>> Modules linked in: video output button battery floppy ac lp parport_pc
>> parport nvram amd_rng rng_core i2c_amd756 i2c_core
>> Pid: 1522, comm: head Not tainted 2.6.23-rc1-autokern1 #1
>> RIP: 0010:[<ffffffff8037379b>]  [<ffffffff8037379b>]
>> acpi_processor_throttling_seq_show+0xa7/0xd6
>> RSP: 0018:ffff81003c4a5e48  EFLAGS: 00010246
>> RAX: 0000000000000020 RBX: ffff810037ea1800 RCX: 0000000000000000
>> RDX: 000000000000002a RSI: ffffffff80599c02 RDI: ffff810037c6a9c0
>> RBP: ffff810037c6a9c0 R08: ffff81003c3e3051 R09: ffff810037c6a9c0
>> R10: ffffffffffffffff R11: ffffffff80373e66 R12: 0000000000000000
>> R13: 0000000000000000 R14: 0000000000000000 R15: 00007fffd59dcd40
>> FS:  00002b7ad50e36f0(0000) GS:ffff81003ee56b40(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 0000000000000000 CR3: 000000003bd9b000 CR4: 00000000000006e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process head (pid: 1522, threadinfo ffff81003c4a4000, task ffff81003ee81040)
>> Stack:  ffff81003eed7180 ffff810037c6a9c0 0000000000000001 0000000000000001
>>  0000000000002000 ffffffff802a77b3 ffff81003c4a5f50 ffff81003e2f8ec0
>>  ffff810037c6a9f0 ffff81003de65000 0000000000000000 fffffffffffffffb
>> Call Trace:
>>  [<ffffffff802a77b3>] seq_read+0x105/0x28e
>>  [<ffffffff802a76ae>] seq_read+0x0/0x28e
>>  [<ffffffff802c8501>] proc_reg_read+0x80/0x9a
>>  [<ffffffff8028eb3d>] vfs_read+0xcb/0x153
>>  [<ffffffff8028eed9>] sys_read+0x45/0x6e
>>  [<ffffffff8020bc6e>] system_call+0x7e/0x83
>> FATAL: Error inserting acpi_cpufreq
>> (/lib/modules/2.6.23-rc1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
>> No such device
>>
>> Full oops is at http://test.kernel.org/abat/100837/debug/console.log
>> Config file at http://test.kernel.org/abat/100837/build/dotconfig
>
> try this,
> thanks,
> -Len
>
> Subject: fix oops due to typo in new throttling code
> From: Luming Yu <luming.yu@gmail.com>
>

This works. When applied, the output to console is

FATAL: Error inserting acpi_cpufreq 
(/lib/modules/2.6.23-rc1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device

Thanks Len

>
> Signed-off-by: Luming Yu <luming.yu@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Len Brown <len.brown@intel.com>
>

Tested-by: Mel Gorman <mel@csn.ul.ie>

> ---
>
> drivers/acpi/processor_throttling.c |    6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> Index: linus/drivers/acpi/processor_throttling.c
> ===================================================================
> --- linus.orig/drivers/acpi/processor_throttling.c
> +++ linus/drivers/acpi/processor_throttling.c
> @@ -658,18 +658,20 @@ static int acpi_processor_throttling_seq
> 		   pr->throttling.state_count - 1);
>
> 	seq_puts(seq, "states:\n");
> -	if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
> +	if (pr->throttling.acpi_processor_get_throttling ==
> +			acpi_processor_get_throttling_fadt) {
> 		for (i = 0; i < pr->throttling.state_count; i++)
> 			seq_printf(seq, "   %cT%d:                  %02d%%\n",
> 				   (i == pr->throttling.state ? '*' : ' '), i,
> 				   (pr->throttling.states[i].performance ? pr->
> 				    throttling.states[i].performance / 10 : 0));
> -	else
> +	} else {
> 		for (i = 0; i < pr->throttling.state_count; i++)
> 			seq_printf(seq, "   %cT%d:                  %02d%%\n",
> 				   (i == pr->throttling.state ? '*' : ' '), i,
> 				   (int)pr->throttling.states_tss[i].
> 				   freqpercentage);
> +	}
>
>       end:
> 	return 0;
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: Linus 2.6.23-rc1

[Gabriel C]

Gabriel C wrote:
[ fixed CC , sorry to that ]

> Linus Torvalds wrote:
>> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 
> 
> ...
> 
> drivers/char/hpet.c:76: warning: integer constant is too large for 'long' type
> 
> ...
> 
> Introduced by 0aa366f351d044703e25c8425e508170e80d83b1 
> 
> 
> 
> 
> 

Re: Linus 2.6.23-rc1

[Bob Picco]

Gabriel C wrote:	[Sun Jul 22 2007, 10:00:39PM EDT]
> Linus Torvalds wrote:
> > Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 
> 
> ...
> 
> drivers/char/hpet.c:76: warning: integer constant is too large for 'long' type
> 
> ...
> 
> Introduced by 0aa366f351d044703e25c8425e508170e80d83b1 
> 
> 
> 
> 

Sorry about that. I thought my review had caught all of these.

Signed-off-by: Bob Picco <bob.picco@hp.com>

 drivers/char/hpet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23-rc1/drivers/char/hpet.c
===================================================================
--- linux-2.6.23-rc1.orig/drivers/char/hpet.c	2007-07-23 10:08:58.000000000 -0400
+++ linux-2.6.23-rc1/drivers/char/hpet.c	2007-07-23 11:46:12.000000000 -0400
@@ -73,7 +73,7 @@ static struct clocksource clocksource_hp
         .name           = "hpet",
         .rating         = 250,
         .read           = read_hpet,
-        .mask           = 0xffffffffffffffff,
+        .mask           = 0xffffffffffffffffULL,
         .mult           = 0, /*to be caluclated*/
         .shift          = 10,
         .flags          = CLOCK_SOURCE_IS_CONTINUOUS,

RE: Linus 2.6.23-rc1

[Luck, Tony]

> Sorry about that. I thought my review had caught all of these.

I missed it too (my old gcc version 3.4.6 doesn't pop a warning
for this).

Presumably the same change is needed for clocksource_itc in
arch/ia64/kernel/time.c

-Tony

Re: Linus 2.6.23-rc1, xen fix

[Ingo Molnar]

Subject: xen: fix process_msg() use-after-kfree
From: Ingo Molnar <mingo@elte.hu>

fix an obvious use-after-kfree bug in Xen.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/xen/xenbus/xenbus_xs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/drivers/xen/xenbus/xenbus_xs.c
===================================================================
--- linux.orig/drivers/xen/xenbus/xenbus_xs.c
+++ linux/drivers/xen/xenbus/xenbus_xs.c
@@ -782,8 +782,8 @@ static int process_msg(void)
 		msg->u.watch.vec = split(body, msg->hdr.len,
 					 &msg->u.watch.vec_size);
 		if (IS_ERR(msg->u.watch.vec)) {
-			kfree(msg);
 			err = PTR_ERR(msg->u.watch.vec);
+			kfree(msg);
 			goto out;
 		}
 

Re: Linus 2.6.23-rc1

[Gabriel C]

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

I get some ACPI Exception.

...

[   33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126]
[   33.075437] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
[   33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126]
[   33.075497] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
[   33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126]
[   33.075536] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
[   33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126]
[   33.075570] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]

...


Config attached.


Regards,

Gabriel C

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

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 18:29:13 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y

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

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
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_PARAVIRT 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_MCORE2 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_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
# CONFIG_HPET_TIMER is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
CONFIG_EDD=y
CONFIG_DELL_RBU=y
CONFIG_DCDBAS=y
CONFIG_DMIID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_X86_PAE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
# CONFIG_HOTPLUG_CPU is not set
# CONFIG_COMPAT_VDSO is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# 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=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m

#
# 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=y
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m

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

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_VERBOSE is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=y
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
# CONFIG_NF_CT_PROTO_UDPLITE is not set
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_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 is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
CONFIG_ATM=y
# CONFIG_ATM_CLIP is not set
# CONFIG_ATM_LANE is not set
# CONFIG_ATM_BR2684 is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_LTPC=m
CONFIG_COPS=m
# CONFIG_COPS_DAYNA is not set
# CONFIG_COPS_TANGENT is not set
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
# CONFIG_NET_SCH_ATM is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RR=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=m
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
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=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_PEDIT=m
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_CLS_POLICE is not set
CONFIG_NET_CLS_IND=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y

#
# Wireless
#
CONFIG_CFG80211=m
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=m
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=m
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
# CONFIG_PARIDE_PT is not set
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
# CONFIG_PARIDE_ATEN is not set
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_BPCK6 is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
# CONFIG_PARIDE_FIT3 is not set
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
# CONFIG_PARIDE_KTTI is not set
# CONFIG_PARIDE_ON20 is not set
# CONFIG_PARIDE_ON26 is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not 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_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_EEPROM_93CX6=m
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_IDE is not set

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

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

#
# 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
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# 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=y
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_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
CONFIG_SCSI_BUSLOGIC=y
CONFIG_SCSI_OMIT_FLASHPOINT=y
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA 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_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC 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
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_ISAPNP is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_WINBOND_VLB is not set
# CONFIG_MD is not set

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

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_NET_SB1000=m
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_ICPLUS_PHY=m
CONFIG_FIXED_PHY=m
CONFIG_FIXED_MII_10_FDX=y
CONFIG_FIXED_MII_100_FDX=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# 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=m
# CONFIG_PCNET32_NAPI 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 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=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set

#
# USB Network Adapters
#
# 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_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
CONFIG_ATM_DRIVERS=y
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
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_PPP_MPPE=m
CONFIG_PPPOE=m
# CONFIG_PPPOATM is not set
# CONFIG_PPPOL2TP is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m

#
# 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 Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
# CONFIG_MOUSE_APPLETOUCH is not set
CONFIG_MOUSE_INPORT=m
# CONFIG_MOUSE_ATIXL is not set
CONFIG_MOUSE_LOGIBM=m
CONFIG_MOUSE_PC110PAD=m
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=m

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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_MOXA_SMARTIO_NEW is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=m
CONFIG_SERIAL_8250_ACCENT=m
CONFIG_SERIAL_8250_BOCA=m
CONFIG_SERIAL_8250_EXAR_ST16C554=m
CONFIG_SERIAL_8250_HUB6=m
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI 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=m
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# 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_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC 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_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB 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

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 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

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 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_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_VIVI=m
# 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_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_TUNER_TEA5761 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN 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_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_V4L_USB_DRIVERS=y
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF 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
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DVB_CORE is not set
CONFIG_VIDEO_BUF=m
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_PROGEAR is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y

#
# Display hardware drivers
#
CONFIG_VGASTATE=y
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=y
CONFIG_FB_VESA=y
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# 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
# CONFIG_FONT_10x18 is not set
# 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_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m

#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 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_OPL3SA2 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_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# 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_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X 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_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
CONFIG_SND_INTEL8X0M=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_AC97_POWER_SAVE=y

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
# CONFIG_SND_USB_CAIAQ_INPUT is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# SoC Audio support for SuperH
#

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

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

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

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

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

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

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX 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_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#
# CONFIG_USB_ATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
# CONFIG_EDAC_AMD76X is not set
CONFIG_EDAC_E7XXX=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_I82860=m
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_I5000=m

#
# Real Time Clock
#
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
# CONFIG_RTC_DRV_M41T80_WDT is not set

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_STK17TA8=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_M48T86=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_V3020=m

#
# on-CPU RTC drivers
#

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m
# CONFIG_AUXDISPLAY is not set
# CONFIG_VIRTUALIZATION is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4DEV_FS=m
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
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_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_ECRYPT_FS=m
# 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=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BIND34=y
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# 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=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# 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=m

#
# Distributed Lock Manager
#
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set
# CONFIG_INSTRUMENTATION is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_SLUB_DEBUG_ON is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_ROOTPLUG=m
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ABLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=y
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

Re: Linus 2.6.23-rc1

[Ismail Dönmez]

On Monday 23 July 2007 19:43:56 Gabriel C wrote:
> I get some ACPI Exception.
>
> ...
>
> [   33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> Evaluating _PTC [20070126] [   33.075437] ACPI Exception
> (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [  
> 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> Evaluating _PTC [20070126] [   33.075497] ACPI Exception
> (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [  
> 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> Evaluating _PTC [20070126] [   33.075536] ACPI Exception
> (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [  
> 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> Evaluating _PTC [20070126] [   33.075570] ACPI Exception
> (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
>

Same here, I was about to blame my holy Vaio, but latest ACPI merge is to 
blame instead.

Regards,
ismail

-- 
Perfect is the enemy of good

Re: Linus 2.6.23-rc1

[Alessandro Suardi]

On 7/23/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> On Monday 23 July 2007 19:43:56 Gabriel C wrote:
> > I get some ACPI Exception.
> >
> > ...
> >
> > [   33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > Evaluating _PTC [20070126] [   33.075437] ACPI Exception
> > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > Evaluating _PTC [20070126] [   33.075497] ACPI Exception
> > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > Evaluating _PTC [20070126] [   33.075536] ACPI Exception
> > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > Evaluating _PTC [20070126] [   33.075570] ACPI Exception
> > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
> >
>
> Same here, I was about to blame my holy Vaio, but latest ACPI merge is to
> blame instead.

Add me too, Dell D610, 2.6.23-rc1 on top of Fedora 7.

--alessandro

 "Did you get married but forgot to get divorced ?"

     (Danny and Dusty, 'The Good Old Days')

Re: Linus 2.6.23-rc1

[Len Brown]

On Monday 23 July 2007 16:44, Alessandro Suardi wrote:
> On 7/23/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> > On Monday 23 July 2007 19:43:56 Gabriel C wrote:
> > > I get some ACPI Exception.
> > >
> > > ...
> > >
> > > [   33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > > Evaluating _PTC [20070126] [   33.075437] ACPI Exception
> > > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > > 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > > Evaluating _PTC [20070126] [   33.075497] ACPI Exception
> > > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > > 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > > Evaluating _PTC [20070126] [   33.075536] ACPI Exception
> > > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
> > > 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
> > > Evaluating _PTC [20070126] [   33.075570] ACPI Exception
> > > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
> > >
> >
> > Same here, I was about to blame my holy Vaio, but latest ACPI merge is to
> > blame instead.
> 
> Add me too, Dell D610, 2.6.23-rc1 on top of Fedora 7.
> 

Ignore it -- it is a new patch looking for optional hooks,
and it is simply too verbose when it doesn't find them.
the verbosity will be gone in rc2.

thanks,
-Len

2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
nothing unusual for this box (two times it was under X, so I can't
guarantee, one time while trying to reproduce via ./configure in gdb
tarball)

Box has 2.5G of RAM. 2.6.22 was OK.

[dives into framebuffer console setup for complete oops]


CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_MCE=y
CONFIG_VM86=y
CONFIG_HIGHMEM4G=y
CONFIG_VMSPLIT_3G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
CONFIG_MTRR=y
CONFIG_HZ_250=y
CONFIG_HZ=250
CONFIG_PHYSICAL_START=0x100000
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA_DMA_API=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_FIB_HASH=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_MISC_DEVICES=y
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ATA=y
CONFIG_ATA_PIIX=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_FB=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_INTEL8X0=y
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_REISERFS_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_FAT_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=866
CONFIG_FAT_DEFAULT_IOCHARSET="koi8-r"
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_UFS_FS=y
CONFIG_UFS_FS_WRITE=y
CONFIG_CIFS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_UTF8=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_RODATA=y
CONFIG_4KSTACKS=y
CONFIG_DOUBLEFAULT=y
CONFIG_BITREVERSE=y
CONFIG_CRC32=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Mon, Jul 23, 2007 at 10:38:39PM +0400, Alexey Dobriyan wrote:
> Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
> nothing unusual for this box (two times it was under X, so I can't
> guarantee, one time while trying to reproduce via ./configure in gdb
> tarball)
> 
> Box has 2.5G of RAM. 2.6.22 was OK.
> 
> [dives into framebuffer console setup for complete oops]

kernel BUG at arch/i386/mm/highmem.c:38
PREEMPT DEBUG_PAGEALLOC SLAB
EIP at kmap_atomic_prot+0x32/0x93
	get_page_from_freelist
	__alloc_pages
	cache_alloc_refill
	cache_alloc_refill
	kmem_cache_alloc
	dst_alloc
	dst_alloc
	__ip_route_output_key
	[some junk I don't trust]

eax: 0000000c
ebx: 00000003
ecx: c065efe0
edx: 00000003
edi: 00000163


c010cc9b <kmap_atomic_prot>:
c010cc9b:	57                   	push   %edi
c010cc9c:	56                   	push   %esi
c010cc9d:	53                   	push   %ebx
c010cc9e:	89 c6                	mov    %eax,%esi
c010cca0:	89 d3                	mov    %edx,%ebx
c010cca2:	89 cf                	mov    %ecx,%edi
c010cca4:	b8 01 00 00 00       	mov    $0x1,%eax
c010cca9:	e8 dd 1b 00 00       	call   c010e88b <add_preempt_count>
c010ccae:	e8 b1 ac 0e 00       	call   c01f7964 <debug_smp_processor_id>
c010ccb3:	6b c0 0d             	imul   $0xd,%eax,%eax
c010ccb6:	8d 14 03             	lea    (%ebx,%eax,1),%edx
c010ccb9:	8d 04 95 00 00 00 00 	lea    0x0(,%edx,4),%eax
c010ccc0:	8b 0d 30 a1 3e c0    	mov    0xc03ea130,%ecx
c010ccc6:	29 c1                	sub    %eax,%ecx
c010ccc8:	83 39 00             	cmpl   $0x0,(%ecx)
c010cccb:	74 04                	je     c010ccd1 <kmap_atomic_prot+0x36>
c010cccd:	0f 0b                	ud2a   

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Mon, 23 Jul 2007 23:01:52 +0400
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Mon, Jul 23, 2007 at 10:38:39PM +0400, Alexey Dobriyan wrote:
> > Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
> > nothing unusual for this box (two times it was under X, so I can't
> > guarantee, one time while trying to reproduce via ./configure in gdb
> > tarball)

Yeah, I hit this several times a few days ago.  Same story: it just
randomly went splat in response to no obvious stimulus.  Reported it to
netdev, was greeted with stunned silence.


> > Box has 2.5G of RAM. 2.6.22 was OK.
> > 
> > [dives into framebuffer console setup for complete oops]
> 
> kernel BUG at arch/i386/mm/highmem.c:38
> PREEMPT DEBUG_PAGEALLOC SLAB
> EIP at kmap_atomic_prot+0x32/0x93
> 	get_page_from_freelist
> 	__alloc_pages
> 	cache_alloc_refill
> 	cache_alloc_refill
> 	kmem_cache_alloc
> 	dst_alloc
> 	dst_alloc
> 	__ip_route_output_key
> 	[some junk I don't trust]
> 
> eax: 0000000c
> ebx: 00000003
> ecx: c065efe0
> edx: 00000003
> edi: 00000163
> 
> 
> c010cc9b <kmap_atomic_prot>:
> c010cc9b:	57                   	push   %edi
> c010cc9c:	56                   	push   %esi
> c010cc9d:	53                   	push   %ebx
> c010cc9e:	89 c6                	mov    %eax,%esi
> c010cca0:	89 d3                	mov    %edx,%ebx
> c010cca2:	89 cf                	mov    %ecx,%edi
> c010cca4:	b8 01 00 00 00       	mov    $0x1,%eax
> c010cca9:	e8 dd 1b 00 00       	call   c010e88b <add_preempt_count>
> c010ccae:	e8 b1 ac 0e 00       	call   c01f7964 <debug_smp_processor_id>
> c010ccb3:	6b c0 0d             	imul   $0xd,%eax,%eax
> c010ccb6:	8d 14 03             	lea    (%ebx,%eax,1),%edx
> c010ccb9:	8d 04 95 00 00 00 00 	lea    0x0(,%edx,4),%eax
> c010ccc0:	8b 0d 30 a1 3e c0    	mov    0xc03ea130,%ecx
> c010ccc6:	29 c1                	sub    %eax,%ecx
> c010ccc8:	83 39 00             	cmpl   $0x0,(%ecx)
> c010cccb:	74 04                	je     c010ccd1 <kmap_atomic_prot+0x36>
> c010cccd:	0f 0b                	ud2a   

I had more complete info: http://article.gmane.org/gmane.linux.network/66966

You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.

I haven't worked out where that kmap_atomic() call is coming from yet. 
Both traces point up into the page allocator, but I _think_ that's stack
gunk.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Mon, Jul 23, 2007 at 01:24:31PM -0700, Andrew Morton wrote:
> On Mon, 23 Jul 2007 23:01:52 +0400
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> 
> > On Mon, Jul 23, 2007 at 10:38:39PM +0400, Alexey Dobriyan wrote:
> > > Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
> > > nothing unusual for this box (two times it was under X, so I can't
> > > guarantee, one time while trying to reproduce via ./configure in gdb
> > > tarball)
> 
> Yeah, I hit this several times a few days ago.  Same story: it just
> randomly went splat in response to no obvious stimulus.  Reported it to
> netdev, was greeted with stunned silence.
> 
> 
> > > Box has 2.5G of RAM. 2.6.22 was OK.
> > > 
> > > [dives into framebuffer console setup for complete oops]
> > 
> > kernel BUG at arch/i386/mm/highmem.c:38
> > PREEMPT DEBUG_PAGEALLOC SLAB
> > EIP at kmap_atomic_prot+0x32/0x93
> > 	get_page_from_freelist
> > 	__alloc_pages
> > 	cache_alloc_refill
> > 	cache_alloc_refill
> > 	kmem_cache_alloc
> > 	dst_alloc
> > 	dst_alloc
> > 	__ip_route_output_key
> > 	[some junk I don't trust]
> > 
> > eax: 0000000c
> > ebx: 00000003
> > ecx: c065efe0
> > edx: 00000003
> > edi: 00000163
> > 
> > 
> > c010cc9b <kmap_atomic_prot>:
> > c010cc9b:	57                   	push   %edi
> > c010cc9c:	56                   	push   %esi
> > c010cc9d:	53                   	push   %ebx
> > c010cc9e:	89 c6                	mov    %eax,%esi
> > c010cca0:	89 d3                	mov    %edx,%ebx
> > c010cca2:	89 cf                	mov    %ecx,%edi
> > c010cca4:	b8 01 00 00 00       	mov    $0x1,%eax
> > c010cca9:	e8 dd 1b 00 00       	call   c010e88b <add_preempt_count>
> > c010ccae:	e8 b1 ac 0e 00       	call   c01f7964 <debug_smp_processor_id>
> > c010ccb3:	6b c0 0d             	imul   $0xd,%eax,%eax
> > c010ccb6:	8d 14 03             	lea    (%ebx,%eax,1),%edx
> > c010ccb9:	8d 04 95 00 00 00 00 	lea    0x0(,%edx,4),%eax
> > c010ccc0:	8b 0d 30 a1 3e c0    	mov    0xc03ea130,%ecx
> > c010ccc6:	29 c1                	sub    %eax,%ecx
> > c010ccc8:	83 39 00             	cmpl   $0x0,(%ecx)
> > c010cccb:	74 04                	je     c010ccd1 <kmap_atomic_prot+0x36>
> > c010cccd:	0f 0b                	ud2a   
> 
> I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> 
> You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> 
> I haven't worked out where that kmap_atomic() call is coming from yet. 
> Both traces point up into the page allocator, but I _think_ that's stack
> gunk.

Ahh, you suspect networking.

Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
receiving ~20 junk packets per second, one gathering netconsole output
and ssh to it, no conntracks and fancy stuff.

[reboots with cables physically unplugged]

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > 
> > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > 
> > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > Both traces point up into the page allocator, but I _think_ that's stack
> > gunk.
> 
> Ahh, you suspect networking.
> 
> Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> receiving ~20 junk packets per second, one gathering netconsole output
> and ssh to it, no conntracks and fancy stuff.
> 
> [reboots with cables physically unplugged]

OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
small files) with both cables unplugged. It all went fine for ~5 minutes
after that it crashed exactly same way after 10 secs after plugging one
of them.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Tue, 24 Jul 2007 01:01:53 +0400
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > > 
> > > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > > 
> > > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > > Both traces point up into the page allocator, but I _think_ that's stack
> > > gunk.
> > 
> > Ahh, you suspect networking.
> > 
> > Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> > receiving ~20 junk packets per second, one gathering netconsole output
> > and ssh to it, no conntracks and fancy stuff.
> > 
> > [reboots with cables physically unplugged]
> 
> OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
> small files) with both cables unplugged. It all went fine for ~5 minutes
> after that it crashed exactly same way after 10 secs after plugging one
> of them.

It'd be nice to get a clean trace.  Are you able to obtain the full
trace with CONFIG_FRAME_POINTER=y?

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Mon, 23 Jul 2007, Andrew Morton wrote:
> 
> It'd be nice to get a clean trace.  Are you able to obtain the full
> trace with CONFIG_FRAME_POINTER=y?

If you are talking about

	http://userweb.kernel.org/~akpm/dsc03659.jpg

then I think that _is_ a full trace. It's certainly not very messy, and it 
seems accurate. It's just that inlining makes it much harder to see the 
call-graphs, but that's what inlining does..

For example, missing from the call graph is

	get_page_from_freelist ->
	  buffered_rmqueue ->		[ missing - inlined ]
	    prep_new_page ->		[ missing - inlined ]
	      prep_zero_page ->		[ missing - inlined ]
		clear_highpage ->	[ missing - inlined ]
		  kmap_atomic ->	[ missing - tailcall ]
		    kmap_atomic_prot

but I'm pretty sure the call trace is good (and I'm also pretty sure gcc 
is overly aggressive at inlining, and that it causes us pain for 
debugging, but whatever)

The earlier part of the trace looks fine too.

The only odd part I see is the existence of "dput()" there, so maybe it's 
not *quite* clean and enabling frame pointers might get rid of a few bogus 
entries, but it looks pretty close to clean.

			Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Sam Ravnborg]

> 
> For example, missing from the call graph is
> 
> 	get_page_from_freelist ->
> 	  buffered_rmqueue ->		[ missing - inlined ]
> 	    prep_new_page ->		[ missing - inlined ]
> 	      prep_zero_page ->		[ missing - inlined ]
> 		clear_highpage ->	[ missing - inlined ]
> 		  kmap_atomic ->	[ missing - tailcall ]
> 		    kmap_atomic_prot
> 
> (and I'm also pretty sure gcc 
> is overly aggressive at inlining, and that it causes us pain for 
> debugging, but whatever)

mm/page_alloc.c:static inline void prep_zero_page(struct page *page, int order, gfp_t gfp_flags)
include/linux/highmem.h:static inline void clear_highpage(struct page *page)

So at least two was explicit marked inline.
Now if that made I change i dunno.

	Sam

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Adrian Bunk]

On Mon, Jul 23, 2007 at 02:28:11PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 23 Jul 2007, Andrew Morton wrote:
> > 
> > It'd be nice to get a clean trace.  Are you able to obtain the full
> > trace with CONFIG_FRAME_POINTER=y?
> 
> If you are talking about
> 
> 	http://userweb.kernel.org/~akpm/dsc03659.jpg
> 
> then I think that _is_ a full trace. It's certainly not very messy, and it 
> seems accurate. It's just that inlining makes it much harder to see the 
> call-graphs, but that's what inlining does..
> 
> For example, missing from the call graph is
> 
> 	get_page_from_freelist ->
> 	  buffered_rmqueue ->		[ missing - inlined ]
> 	    prep_new_page ->		[ missing - inlined ]
> 	      prep_zero_page ->		[ missing - inlined ]
> 		clear_highpage ->	[ missing - inlined ]
> 		  kmap_atomic ->	[ missing - tailcall ]
> 		    kmap_atomic_prot
> 
> but I'm pretty sure the call trace is good (and I'm also pretty sure gcc 
> is overly aggressive at inlining, and that it causes us pain for 
> debugging, but whatever)
>...

For prep_zero_page() and clear_highpage() we can't blame gcc since we 
force gcc to always inline them.

buffered_rmqueue() and prep_new_page() are static functions with only 
one caller each, and for the normal non-debug case it's a really nice 
optimization to have them inlined automatically. But it might make sense 
to add -fno-inline-functions-called-once to the CFLAGS depending on some 
debug option?

> 			Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Tue, 24 Jul 2007, Adrian Bunk wrote:
> 
> buffered_rmqueue() and prep_new_page() are static functions with only 
> one caller each, and for the normal non-debug case it's a really nice 
> optimization to have them inlined automatically.

I'm not at all sure I agree.

Inlining big functions doesn't actually tend to generally generate any 
better code, so if gcc's logic is "single callsite - always inline", then 
that logic is likely not right.

		Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Tue, 24 Jul 2007 11:14:21 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Tue, 24 Jul 2007, Adrian Bunk wrote:
> > 
> > buffered_rmqueue() and prep_new_page() are static functions with only 
> > one caller each, and for the normal non-debug case it's a really nice 
> > optimization to have them inlined automatically.
> 
> I'm not at all sure I agree.
> 
> Inlining big functions doesn't actually tend to generally generate any 
> better code, so if gcc's logic is "single callsite - always inline", then 
> that logic is likely not right.
> 

fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
vmlinux .text from 928360 up to 955362 bytes (27k larger).

A surprisingly large increase - I wonder if it did something dumb.  It
appears to still correctly inline those things which we've manually marked
inline.  hm.

It would be nice to defeat the autoinlining for debug purposes though.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Tue, 24 Jul 2007, Andrew Morton wrote:
> 
> fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
> vmlinux .text from 928360 up to 955362 bytes (27k larger).
> 
> A surprisingly large increase - I wonder if it did something dumb.  It
> appears to still correctly inline those things which we've manually marked
> inline.  hm.

I think inlining small enough functions is worth it, and the thing is, the 
kernel is actually pretty damn good at having lots of small functions. 
It's one of the few things I really care about from a coding style 
standpoint.

So I'm not surprised that "-fno-inline-functions-called-once" makes things 
larger, because I think it's generally a good idea to inline things that 
are just called once. But it does make things harder to debug, and the 
performance advantages become increasingly small for bigger functions.

And that's a balancing act. Do we care about performance? Yes. But do we 
care so much that it's worth inlining something like buffered_rmqueue()? 

So I would not be surprised if "-fno-inline-functions-called-once" will 
disable *all* the inlining heuristics, and say "oh, it's not an inline 
function, and it's only called once, so we won't inline it at all".

So "called once" should probably make the inlining weight bigger (ie 
inline *larger* functions than you would otherwise), it just shouldn't 
make it "infinite". It's not worth it.

		Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Adrian Bunk]

On Tue, Jul 24, 2007 at 12:15:48PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> > 
> > fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig
> > vmlinux .text from 928360 up to 955362 bytes (27k larger).
> > 
> > A surprisingly large increase - I wonder if it did something dumb.  It
> > appears to still correctly inline those things which we've manually marked
> > inline.  hm.
> 
> I think inlining small enough functions is worth it, and the thing is, the 
> kernel is actually pretty damn good at having lots of small functions. 
> It's one of the few things I really care about from a coding style 
> standpoint.
> 
> So I'm not surprised that "-fno-inline-functions-called-once" makes things 
> larger, because I think it's generally a good idea to inline things that 
> are just called once. But it does make things harder to debug, and the 
> performance advantages become increasingly small for bigger functions.
> 
> And that's a balancing act. Do we care about performance? Yes.

When using CONFIG_CC_OPTIMIZE_FOR_SIZE=y we even actively tell gcc that 
we only care about size and do not care about performance...

> But do we 
> care so much that it's worth inlining something like buffered_rmqueue()? 
>...

Where is the problem with having buffered_rmqueue() inlined?

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Tue, 24 Jul 2007, Adrian Bunk wrote:
> 
> > But do we 
> > care so much that it's worth inlining something like buffered_rmqueue()? 
> >...
> 
> Where is the problem with having buffered_rmqueue() inlined?

In this case, it was a pain to just even try to find the call chain, or 
read the asm.

I would encourage lots of kernel hackers to read the assembler code gcc 
generates. I suspect people being aware of code generation issues (and 
writing their code with that in mind) is a *much* bigger performance 
impact than gcc inlining random functions.

So maybe I'm old-fashioned and crazy, but "readability of the asm result" 
actually is a worthwhile goal. Not because we care directly, but because 
I'd like to encourage people to do it, due to the *indirect* benefits.

		Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Adrian Bunk]

On Tue, Jul 24, 2007 at 12:48:13PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 24 Jul 2007, Adrian Bunk wrote:
> > 
> > > But do we 
> > > care so much that it's worth inlining something like buffered_rmqueue()? 
> > >...
> > 
> > Where is the problem with having buffered_rmqueue() inlined?
> 
> In this case, it was a pain to just even try to find the call chain, or 
> read the asm.

Optimization versus debugging is a common issue...

As I said, it might make sense to disable this optimization depending on 
some debugging option.

> I would encourage lots of kernel hackers to read the assembler code gcc 
> generates. I suspect people being aware of code generation issues (and 
> writing their code with that in mind) is a *much* bigger performance 
> impact than gcc inlining random functions.
> 
> So maybe I'm old-fashioned and crazy, but "readability of the asm result" 
> actually is a worthwhile goal. Not because we care directly, but because 
> I'd like to encourage people to do it, due to the *indirect* benefits.

This would lead to people trying to optimize code for one gcc version - 
and the code might stay this way for 10 years.

People should write readable C code. This also has the best chances of 
resulting in good performance with the next gcc version on the next 
generation hardware.

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Thu, 26 Jul 2007, Adrian Bunk wrote:
> > 
> > So maybe I'm old-fashioned and crazy, but "readability of the asm result" 
> > actually is a worthwhile goal. Not because we care directly, but because 
> > I'd like to encourage people to do it, due to the *indirect* benefits.
> 
> This would lead to people trying to optimize code for one gcc version - 
> and the code might stay this way for 10 years.

No. The fact is, code that is easy to optimize is easy to optimize.

It has _nothing_ to do with gcc versions. 

		Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andi Kleen]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> So "called once" should probably make the inlining weight bigger (ie 
> inline *larger* functions than you would otherwise), it just shouldn't 
> make it "infinite". It's not worth it.

There's probably a --param where it can be tweaked exactly. The
problem is that --params tend to be very gcc version specific
and might do something completely different on a newer or 
older version. So it's better not to use them.

-Andi

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Tue, 24 Jul 2007, Andi Kleen wrote:
> 
> There's probably a --param where it can be tweaked exactly. The
> problem is that --params tend to be very gcc version specific
> and might do something completely different on a newer or 
> older version. So it's better not to use them.

I agree wholeheartedly with that sentiment. We've tried at times (because 
some gcc snapshots made some *truly* insane choices for a while), and 
maybe we still have some around. Not worth the pain.

		Linus

Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices - broke my serial console

[H. Peter Anvin]

Jeff Garzik wrote:
> 
> On Tue, 24 Jul 2007, Adrian Bunk wrote:
>> buffered_rmqueue() and prep_new_page() are static functions with only 
>> one caller each, and for the normal non-debug case it's a really nice 
>> optimization to have them inlined automatically.
> 
> I'm not at all sure I agree.
> 
> Inlining big functions doesn't actually tend to generally generate any 
> better code, so if gcc's logic is "single callsite - always inline", then 
> that logic is likely not right.
> 

Only up to a threshold, as far as I know.

	-hpa

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Mon, Jul 23, 2007 at 02:11:37PM -0700, Andrew Morton wrote:
> On Tue, 24 Jul 2007 01:01:53 +0400
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> 
> > On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > > > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > > > 
> > > > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > > > 
> > > > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > > > Both traces point up into the page allocator, but I _think_ that's stack
> > > > gunk.
> > > 
> > > Ahh, you suspect networking.
> > > 
> > > Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> > > receiving ~20 junk packets per second, one gathering netconsole output
> > > and ssh to it, no conntracks and fancy stuff.
> > > 
> > > [reboots with cables physically unplugged]
> > 
> > OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
> > small files) with both cables unplugged. It all went fine for ~5 minutes
> > after that it crashed exactly same way after 10 secs after plugging one
> > of them.
> 
> It'd be nice to get a clean trace.  Are you able to obtain the full
> trace with CONFIG_FRAME_POINTER=y?

Sorry, no camera shot, finding camera requires wakening up M. :)

It took longer that usual, but here it is

	kmap_atomic
	get_page_from_freelist
	__alloc_pages
	cache_alloc_refill
	__alloc_pages
	cache_alloc_refill
	kmem_cache_alloc
	dst_alloc
	ip_route_input
	ip_rcv
	netif_receive_skb
	rtl8139_poll
	net_rx_action
	__do_softirq
	do_softirq
	irq_exit
	do_IRQ
	common_interrupt
	handle_mm_fault
	do_page_fault
	error_core

much more loaded x86_64 box near also running 2.6.23-rc1 with debugging
turned on, using atl1 driver doesn't experience any crashes.

And I found 2.6.22-b91cba52e9b7b3f1c0037908a192d93a869ca9e5-x entry on
top of grub config which means b91cba52e9b7b3f1c0037908a192d93a869ca9e5
_without_ any debugging was OK.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Tue, 24 Jul 2007 02:04:46 +0400
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Mon, Jul 23, 2007 at 02:11:37PM -0700, Andrew Morton wrote:
> > On Tue, 24 Jul 2007 01:01:53 +0400
> > Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > 
> > > On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > > > > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > > > > 
> > > > > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > > > > 
> > > > > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > > > > Both traces point up into the page allocator, but I _think_ that's stack
> > > > > gunk.
> > > > 
> > > > Ahh, you suspect networking.
> > > > 
> > > > Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> > > > receiving ~20 junk packets per second, one gathering netconsole output
> > > > and ssh to it, no conntracks and fancy stuff.
> > > > 
> > > > [reboots with cables physically unplugged]
> > > 
> > > OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
> > > small files) with both cables unplugged. It all went fine for ~5 minutes
> > > after that it crashed exactly same way after 10 secs after plugging one
> > > of them.
> > 
> > It'd be nice to get a clean trace.  Are you able to obtain the full
> > trace with CONFIG_FRAME_POINTER=y?
> 
> Sorry, no camera shot, finding camera requires wakening up M. :)
> 
> It took longer that usual, but here it is
> 
> 	kmap_atomic
> 	get_page_from_freelist
> 	__alloc_pages
> 	cache_alloc_refill
> 	__alloc_pages
> 	cache_alloc_refill
> 	kmem_cache_alloc
> 	dst_alloc
> 	ip_route_input
> 	ip_rcv
> 	netif_receive_skb
> 	rtl8139_poll
> 	net_rx_action
> 	__do_softirq
> 	do_softirq
> 	irq_exit
> 	do_IRQ
> 	common_interrupt
> 	handle_mm_fault
> 	do_page_fault
> 	error_core
> 
> much more loaded x86_64 box near also running 2.6.23-rc1 with debugging
> turned on, using atl1 driver doesn't experience any crashes.
> 
> And I found 2.6.22-b91cba52e9b7b3f1c0037908a192d93a869ca9e5-x entry on
> top of grub config which means b91cba52e9b7b3f1c0037908a192d93a869ca9e5
> _without_ any debugging was OK.

I worked out that the crash I saw was in

        BUG_ON(!pte_none(*(kmap_pte-idx)));

in the read of kmap_pte[idx].  Which would be weird as the caller is using 
a literal KM_USER0.

So maybe I goofed, and that BUG_ON is triggering (it scrolled off, and I am
unable to reproduce it now).

If that BUG_ON _is_ triggering then it might indicate that someone is doing
a __GFP_HIGHMEM|__GFP_ZERO allocation while holding KM_USER0.

If they're holding an atomic kmap then they'll be running in_atomic so it
is unlikely that they accidentally added __GFP_WAIT because lots of people
would be getting lots of might_sleep() warnings.

Hence that first VM_BUG_ON in prep_zero_page() _should_ be triggering.

Do you have CONFIG_DEBUG_VM enabled?



Also, it might be useful to apply -mm's kmap_atomic-debugging.patch.  it
will detect lots of abuse.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Mon, Jul 23, 2007 at 03:27:12PM -0700, Andrew Morton wrote:
> On Tue, 24 Jul 2007 02:04:46 +0400
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> 
> > On Mon, Jul 23, 2007 at 02:11:37PM -0700, Andrew Morton wrote:
> > > On Tue, 24 Jul 2007 01:01:53 +0400
> > > Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > > 
> > > > On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > > > > > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > > > > > 
> > > > > > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > > > > > 
> > > > > > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > > > > > Both traces point up into the page allocator, but I _think_ that's stack
> > > > > > gunk.
> > > > > 
> > > > > Ahh, you suspect networking.
> > > > > 
> > > > > Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> > > > > receiving ~20 junk packets per second, one gathering netconsole output
> > > > > and ssh to it, no conntracks and fancy stuff.
> > > > > 
> > > > > [reboots with cables physically unplugged]
> > > > 
> > > > OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
> > > > small files) with both cables unplugged. It all went fine for ~5 minutes
> > > > after that it crashed exactly same way after 10 secs after plugging one
> > > > of them.
> > > 
> > > It'd be nice to get a clean trace.  Are you able to obtain the full
> > > trace with CONFIG_FRAME_POINTER=y?
> > 
> > Sorry, no camera shot, finding camera requires wakening up M. :)
> > 
> > It took longer that usual, but here it is
> > 
> > 	kmap_atomic
> > 	get_page_from_freelist
> > 	__alloc_pages
> > 	cache_alloc_refill
> > 	__alloc_pages
> > 	cache_alloc_refill
> > 	kmem_cache_alloc
> > 	dst_alloc
> > 	ip_route_input
> > 	ip_rcv
> > 	netif_receive_skb
> > 	rtl8139_poll
> > 	net_rx_action
> > 	__do_softirq
> > 	do_softirq
> > 	irq_exit
> > 	do_IRQ
> > 	common_interrupt
> > 	handle_mm_fault
> > 	do_page_fault
> > 	error_core
> > 
> > much more loaded x86_64 box near also running 2.6.23-rc1 with debugging
> > turned on, using atl1 driver doesn't experience any crashes.
> > 
> > And I found 2.6.22-b91cba52e9b7b3f1c0037908a192d93a869ca9e5-x entry on
> > top of grub config which means b91cba52e9b7b3f1c0037908a192d93a869ca9e5
> > _without_ any debugging was OK.
> 
> I worked out that the crash I saw was in
> 
>         BUG_ON(!pte_none(*(kmap_pte-idx)));
> 
> in the read of kmap_pte[idx].  Which would be weird as the caller is using 
> a literal KM_USER0.
> 
> So maybe I goofed, and that BUG_ON is triggering (it scrolled off, and I am
> unable to reproduce it now).
> 
> If that BUG_ON _is_ triggering then it might indicate that someone is doing
> a __GFP_HIGHMEM|__GFP_ZERO allocation while holding KM_USER0.
> 
> If they're holding an atomic kmap then they'll be running in_atomic so it
> is unlikely that they accidentally added __GFP_WAIT because lots of people
> would be getting lots of might_sleep() warnings.
> 
> Hence that first VM_BUG_ON in prep_zero_page() _should_ be triggering.
> 
> Do you have CONFIG_DEBUG_VM enabled?

Yes.

> Also, it might be useful to apply -mm's kmap_atomic-debugging.patch.  it
> will detect lots of abuse.

I hit it only once with this patch applied, but there were no additional
warnings.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Jens Axboe]

On Mon, Jul 23 2007, Andrew Morton wrote:
> I worked out that the crash I saw was in
> 
>         BUG_ON(!pte_none(*(kmap_pte-idx)));
> 
> in the read of kmap_pte[idx].  Which would be weird as the caller is using 
> a literal KM_USER0.
> 
> So maybe I goofed, and that BUG_ON is triggering (it scrolled off, and I am
> unable to reproduce it now).
> 
> If that BUG_ON _is_ triggering then it might indicate that someone is doing
> a __GFP_HIGHMEM|__GFP_ZERO allocation while holding KM_USER0.

Or doing double kunmaps, or doing a kunmap_atomic() on the page, not the
address. I've seen both of those end up triggering that BUG_ON() in a
later kmap.

Looking over the 2.6.22..2.6.23-rc1 diff, I found one such error in
ocfs2 at least. But you are probably not using that, so I'll keep
looking...

---

[PATCH] ocfs2: bad kunmap_atomic()

kunmap_atomic() takes the virtual address, not the mapped page as
argument.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index 5727cd1..c4034f6 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -2153,7 +2153,7 @@ static int ocfs2_splice_write_actor(struct pipe_inode_info *pipe,
 	src = buf->ops->map(pipe, buf, 1);
 	dst = kmap_atomic(page, KM_USER1);
 	memcpy(dst + offset, src + buf->offset, count);
-	kunmap_atomic(page, KM_USER1);
+	kunmap_atomic(dst, KM_USER1);
 	buf->ops->unmap(pipe, buf, src);
 
 	copied = ocfs2_write_end(file, file->f_mapping, sd->pos, count, count,

-- 
Jens Axboe

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Jens Axboe]

On Tue, Jul 24 2007, Jens Axboe wrote:
> On Mon, Jul 23 2007, Andrew Morton wrote:
> > I worked out that the crash I saw was in
> > 
> >         BUG_ON(!pte_none(*(kmap_pte-idx)));
> > 
> > in the read of kmap_pte[idx].  Which would be weird as the caller is using 
> > a literal KM_USER0.
> > 
> > So maybe I goofed, and that BUG_ON is triggering (it scrolled off, and I am
> > unable to reproduce it now).
> > 
> > If that BUG_ON _is_ triggering then it might indicate that someone is doing
> > a __GFP_HIGHMEM|__GFP_ZERO allocation while holding KM_USER0.
> 
> Or doing double kunmaps, or doing a kunmap_atomic() on the page, not the
> address. I've seen both of those end up triggering that BUG_ON() in a
> later kmap.
> 
> Looking over the 2.6.22..2.6.23-rc1 diff, I found one such error in
> ocfs2 at least. But you are probably not using that, so I'll keep
> looking...

What about the new async crypto stuff? I've been looking, but is it
guarenteed that async_memcpy() runs in process context with interrupts
enabled always? If not, there's a km type bug there.

In general, I think the highmem stuff could do with more safety checks:

- People ALWAYS get the atomic unmaps wrong, passing in the page instead
  of the address. I've seen tons of these. And since kunmap_atomic()
  takes a void pointer, nobody notices until it goes boom.
- People easily get the km type wrong - they use KM_USERx in interrupt
  context, or one of the irq variants without disabling interrupts.

If we could just catch these two types of bugs, we've got a lot of these
problems covered.


-- 
Jens Axboe

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Tue, 24 Jul 2007 10:22:07 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:

> On Tue, Jul 24 2007, Jens Axboe wrote:
> > On Mon, Jul 23 2007, Andrew Morton wrote:
> > > I worked out that the crash I saw was in
> > > 
> > >         BUG_ON(!pte_none(*(kmap_pte-idx)));
> > > 
> > > in the read of kmap_pte[idx].  Which would be weird as the caller is using 
> > > a literal KM_USER0.
> > > 
> > > So maybe I goofed, and that BUG_ON is triggering (it scrolled off, and I am
> > > unable to reproduce it now).
> > > 
> > > If that BUG_ON _is_ triggering then it might indicate that someone is doing
> > > a __GFP_HIGHMEM|__GFP_ZERO allocation while holding KM_USER0.
> > 
> > Or doing double kunmaps, or doing a kunmap_atomic() on the page, not the
> > address. I've seen both of those end up triggering that BUG_ON() in a
> > later kmap.
> > 
> > Looking over the 2.6.22..2.6.23-rc1 diff, I found one such error in
> > ocfs2 at least. But you are probably not using that, so I'll keep
> > looking...
> 
> What about the new async crypto stuff? I've been looking, but is it
> guarenteed that async_memcpy() runs in process context with interrupts
> enabled always? If not, there's a km type bug there.

I think Shannon maintains that now.

> In general, I think the highmem stuff could do with more safety checks:
> 
> - People ALWAYS get the atomic unmaps wrong, passing in the page instead
>   of the address. I've seen tons of these. And since kunmap_atomic()
>   takes a void pointer, nobody notices until it goes boom.

yeah, it's a real trap.  For a while I had a patch which converted
kmap_atomic() to return a char*, and kunmap_atomic() to take a char*, so
misuse got compile warnings.  But it was a pig to maintain so I tossed it. 
It'd be somewhat easier to do now we've converted a lot of callers to
clear_user_highpage() and similar.

> - People easily get the km type wrong - they use KM_USERx in interrupt
>   context, or one of the irq variants without disabling interrupts.
> 
> If we could just catch these two types of bugs, we've got a lot of these
> problems covered.

Here's the -mm debug patch:


diff -puN arch/i386/mm/highmem.c~kmap_atomic-debugging arch/i386/mm/highmem.c
--- a/arch/i386/mm/highmem.c~kmap_atomic-debugging
+++ a/arch/i386/mm/highmem.c
@@ -30,7 +30,44 @@ void *kmap_atomic(struct page *page, enu
 {
 	enum fixed_addresses idx;
 	unsigned long vaddr;
+	static unsigned warn_count = 10;
 
+	if (unlikely(warn_count == 0))
+		goto skip;
+
+	if (unlikely(in_interrupt())) {
+		if (in_irq()) {
+			if (type != KM_IRQ0 && type != KM_IRQ1 &&
+			    type != KM_BIO_SRC_IRQ && type != KM_BIO_DST_IRQ &&
+			    type != KM_BOUNCE_READ) {
+				WARN_ON(1);
+				warn_count--;
+			}
+		} else if (!irqs_disabled()) {	/* softirq */
+			if (type != KM_IRQ0 && type != KM_IRQ1 &&
+			    type != KM_SOFTIRQ0 && type != KM_SOFTIRQ1 &&
+			    type != KM_SKB_SUNRPC_DATA &&
+			    type != KM_SKB_DATA_SOFTIRQ &&
+			    type != KM_BOUNCE_READ) {
+				WARN_ON(1);
+				warn_count--;
+			}
+		}
+	}
+
+	if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ ||
+			type == KM_BIO_SRC_IRQ || type == KM_BIO_DST_IRQ) {
+		if (!irqs_disabled()) {
+			WARN_ON(1);
+			warn_count--;
+		}
+	} else if (type == KM_SOFTIRQ0 || type == KM_SOFTIRQ1) {
+		if (irq_count() == 0 && !irqs_disabled()) {
+			WARN_ON(1);
+			warn_count--;
+		}
+	}
+skip:
 	/* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
 	pagefault_disable();
 
_

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Dan Williams]

On 7/24/07, Andrew Morton <akpm@linux-foundation.org> wrote:
[...]
> > What about the new async crypto stuff? I've been looking, but is it
> > guarenteed that async_memcpy() runs in process context with interrupts
> > enabled always? If not, there's a km type bug there.
>
> I think Shannon maintains that now.
>

I am looking after the async_tx API, I will send a patch to update
MAINTAINERS shortly.

--
Dan

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Dan Williams]

On 7/24/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> What about the new async crypto stuff? I've been looking, but is it
> guarenteed that async_memcpy() runs in process context with interrupts
> enabled always? If not, there's a km type bug there.
>

Currently the only user is the MD raid456 driver, and yes, it only
performs copies from the handle_stripe routine which is always run in
process context with interrupts enabled.  However this is not
documented.  Would it be advisable to add a WARN_ON for this
condition?

> In general, I think the highmem stuff could do with more safety checks:
>
> - People ALWAYS get the atomic unmaps wrong, passing in the page instead
>   of the address. I've seen tons of these. And since kunmap_atomic()
>   takes a void pointer, nobody notices until it goes boom.
> - People easily get the km type wrong - they use KM_USERx in interrupt
>   context, or one of the irq variants without disabling interrupts.
>
> If we could just catch these two types of bugs, we've got a lot of these
> problems covered.
>
>
> --
> Jens Axboe
>
--
Dan

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Mike Galbraith]

On Mon, 2007-07-23 at 13:24 -0700, Andrew Morton wrote:

> You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.

My box bugged during boot the first time I booted 23-rc1, but nothing
made it to the console, and I didn't have a serial console running.  I
didn't have DEBUG_PAGEALLOC or friends set.

> I haven't worked out where that kmap_atomic() call is coming from yet. 
> Both traces point up into the page allocator, but I _think_ that's stack
> gunk.

I just enabled all debug options, and was just rewarded with the below.

[  119.079531] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
[  119.558867] ------------[ cut here ]------------
[  119.572197] kernel BUG at arch/i386/mm/highmem.c:38!
[  119.585804] invalid opcode: 0000 [#1]
[  119.598013] PREEMPT SMP DEBUG_PAGEALLOC
[  119.610103] Modules linked in: edd button battery ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8 snd_intel8x0 snd_ac97_codec ac97_bus snd_mpu401 snd_pcm prism54 snd_timer snd_mpu401_uart snd_rawmidi snd_seq_device snd intel_agp agpgart soundcore snd_page_alloc i2c_i801 fan thermal processor
[  119.698063] CPU:    1
[  119.698065] EIP:    0060:[<c011cd2d>]    Not tainted VLI
[  119.698067] EFLAGS: 00010006   (2.6.23-rc1-smp #75)
[  119.736358] EIP is at kmap_atomic_prot+0xa7/0xab
[  119.749647] eax: 3d07f163   ebx: c166db80   ecx: c0750e60   edx: 00000007
[  119.765417] esi: 00000022   edi: 00000163   ebp: c069dcd4   esp: c069dcc8
[  119.781273] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[  119.796378] Process udevd (pid: 4775, ti=c069d000 task=f31aea60 task.ti=f477d000)
[  119.804068] Stack: c166db80 00000000 c166db80 c069dcdc c011cd3f c069dd40 c015b6e0 00000001 
[  119.822272]        00000044 00000163 00000000 00000001 c165f4e0 00000001 c165f4e0 00000001 
[  119.840762]        00000000 00028020 c061e71c c166db80 00000046 00000080 00000001 c011e4de 
[  119.859389] Call Trace:
[  119.881302]  [<c0105144>] show_trace_log_lvl+0x1a/0x30
[  119.896319]  [<c01051ff>] show_stack_log_lvl+0xa5/0xca
[  119.911171]  [<c0105420>] show_registers+0x1fc/0x343
[  119.925756]  [<c0105689>] die+0x122/0x249
[  119.939241]  [<c0105834>] do_trap+0x84/0xad
[  119.952897]  [<c0105b1c>] do_invalid_op+0x88/0x92
[  119.967118]  [<c04cf3c2>] error_code+0x72/0x78
[  119.980948]  [<c011cd3f>] kmap_atomic+0xe/0x10
[  119.994642]  [<c015b6e0>] get_page_from_freelist+0x39e/0x45e
[  120.009485]  [<c015b7fb>] __alloc_pages+0x5b/0x2db
[  120.023342]  [<c0172872>] cache_alloc_refill+0x380/0x6f2
[  120.037623]  [<c0172e7a>] kmem_cache_alloc+0xa1/0xa5
[  120.051426]  [<c03fb397>] neigh_create+0x5f/0x506
[  120.064894]  [<c046e25d>] ndisc_dst_alloc+0x122/0x151
[  120.078769]  [<c0471b0b>] __ndisc_send+0x8d/0x4fa
[  120.092340]  [<c0472915>] ndisc_send_ns+0x5f/0x7d
[  120.105848]  [<c0469ff5>] addrconf_dad_timer+0xdb/0xe0
[  120.119758]  [<c012f8a0>] run_timer_softirq+0x130/0x191
[  120.133717]  [<c012c06d>] __do_softirq+0x76/0xe4
[  120.147475]  [<c0106b48>] do_softirq+0x63/0xac
[  120.147488]  [<c012bff5>] 

(gdb) list *neigh_create+0x5f
0xc03fb397 is in neigh_create (include/linux/slab.h:259).
254     /*
255      * Shortcuts
256      */
257     static inline void *kmem_cache_zalloc(struct kmem_cache *k, gfp_t flags)
258     {
259             return kmem_cache_alloc(k, flags | __GFP_ZERO);
260     }
261
262     /**
263      * kzalloc - allocate memory. The memory is set to zero.
(gdb) list *kmem_cache_alloc+0xa1
0xc0172e7a is in kmem_cache_alloc (mm/slab.c:3176).
3171                    STATS_INC_ALLOCHIT(cachep);
3172                    ac->touched = 1;
3173                    objp = ac->entry[--ac->avail];
3174            } else {
3175                    STATS_INC_ALLOCMISS(cachep);
3176                    objp = cache_alloc_refill(cachep, flags);
3177            }
3178            return objp;
3179    }
3180
(gdb) list *cache_alloc_refill+0x380
0xc0172872 is in cache_alloc_refill (include/linux/gfp.h:154).
149
150             /* Unknown node is current node */
151             if (nid < 0)
152                     nid = numa_node_id();
153
154             return __alloc_pages(gfp_mask, order,
155                     NODE_DATA(nid)->node_zonelists + gfp_zone(gfp_mask));
156     }
157
158     #ifdef CONFIG_NUMA
(gdb) list *__alloc_pages+0x5b
0xc015b7fb is in __alloc_pages (mm/page_alloc.c:1248).
1243            if (unlikely(*z == NULL)) {
1244                    /* Should this ever happen?? */
1245                    return NULL;
1246            }
1247
1248            page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, order,
1249                                    zonelist, ALLOC_WMARK_LOW|ALLOC_CPUSET);
1250            if (page)
1251                    goto got_pg;
1252
(gdb) list *get_page_from_freelist+0x39e
0xc015b6e0 is in get_page_from_freelist (include/linux/highmem.h:122).
117             return __alloc_zeroed_user_highpage(__GFP_MOVABLE, vma, vaddr);
118     }
119
120     static inline void clear_highpage(struct page *page)
121     {
122             void *kaddr = kmap_atomic(page, KM_USER0);
123             clear_page(kaddr);
124             kunmap_atomic(kaddr, KM_USER0);
125     }
126

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Mike Galbraith]

On Tue, 2007-07-24 at 12:01 +0200, Mike Galbraith wrote:
> On Mon, 2007-07-23 at 13:24 -0700, Andrew Morton wrote:
> 
> > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> 
> My box bugged during boot the first time I booted 23-rc1, but nothing
> made it to the console, and I didn't have a serial console running.  I
> didn't have DEBUG_PAGEALLOC or friends set.
> 
> > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > Both traces point up into the page allocator, but I _think_ that's stack
> > gunk.
> 
> I just enabled all debug options, and was just rewarded with the below.

Hm.  I just also experienced filesystem corruption when I tried to send
from that kernel, and it bugged in the process.  My mount table ended up
in /etc/resolv.conf along with some binary goop, making nscd rather
unhappy after reboot.  fsck time.

	.Mike

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Andrew Morton]

On Tue, 24 Jul 2007 12:01:09 +0200 Mike Galbraith <efault@gmx.de> wrote:

> On Mon, 2007-07-23 at 13:24 -0700, Andrew Morton wrote:
> 
> > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> 
> My box bugged during boot the first time I booted 23-rc1, but nothing
> made it to the console, and I didn't have a serial console running.  I
> didn't have DEBUG_PAGEALLOC or friends set.
> 
> > I haven't worked out where that kmap_atomic() call is coming from yet. 
> > Both traces point up into the page allocator, but I _think_ that's stack
> > gunk.
> 
> I just enabled all debug options, and was just rewarded with the below.

doh.  It's a slab bug.

> [  119.079531] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
> [  119.558867] ------------[ cut here ]------------
> [  119.572197] kernel BUG at arch/i386/mm/highmem.c:38!
> [  119.585804] invalid opcode: 0000 [#1]
> [  119.598013] PREEMPT SMP DEBUG_PAGEALLOC
> [  119.610103] Modules linked in: edd button battery ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8 snd_intel8x0 snd_ac97_codec ac97_bus snd_mpu401 snd_pcm prism54 snd_timer snd_mpu401_uart snd_rawmidi snd_seq_device snd intel_agp agpgart soundcore snd_page_alloc i2c_i801 fan thermal processor
> [  119.698063] CPU:    1
> [  119.698065] EIP:    0060:[<c011cd2d>]    Not tainted VLI
> [  119.698067] EFLAGS: 00010006   (2.6.23-rc1-smp #75)
> [  119.736358] EIP is at kmap_atomic_prot+0xa7/0xab
> [  119.749647] eax: 3d07f163   ebx: c166db80   ecx: c0750e60   edx: 00000007
> [  119.765417] esi: 00000022   edi: 00000163   ebp: c069dcd4   esp: c069dcc8
> [  119.781273] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> [  119.796378] Process udevd (pid: 4775, ti=c069d000 task=f31aea60 task.ti=f477d000)
> [  119.804068] Stack: c166db80 00000000 c166db80 c069dcdc c011cd3f c069dd40 c015b6e0 00000001 
> [  119.822272]        00000044 00000163 00000000 00000001 c165f4e0 00000001 c165f4e0 00000001 
> [  119.840762]        00000000 00028020 c061e71c c166db80 00000046 00000080 00000001 c011e4de 
> [  119.859389] Call Trace:
> [  119.881302]  [<c0105144>] show_trace_log_lvl+0x1a/0x30
> [  119.896319]  [<c01051ff>] show_stack_log_lvl+0xa5/0xca
> [  119.911171]  [<c0105420>] show_registers+0x1fc/0x343
> [  119.925756]  [<c0105689>] die+0x122/0x249
> [  119.939241]  [<c0105834>] do_trap+0x84/0xad
> [  119.952897]  [<c0105b1c>] do_invalid_op+0x88/0x92
> [  119.967118]  [<c04cf3c2>] error_code+0x72/0x78
> [  119.980948]  [<c011cd3f>] kmap_atomic+0xe/0x10
> [  119.994642]  [<c015b6e0>] get_page_from_freelist+0x39e/0x45e
> [  120.009485]  [<c015b7fb>] __alloc_pages+0x5b/0x2db
> [  120.023342]  [<c0172872>] cache_alloc_refill+0x380/0x6f2
> [  120.037623]  [<c0172e7a>] kmem_cache_alloc+0xa1/0xa5
> [  120.051426]  [<c03fb397>] neigh_create+0x5f/0x506
> [  120.064894]  [<c046e25d>] ndisc_dst_alloc+0x122/0x151
> [  120.078769]  [<c0471b0b>] __ndisc_send+0x8d/0x4fa
> [  120.092340]  [<c0472915>] ndisc_send_ns+0x5f/0x7d
> [  120.105848]  [<c0469ff5>] addrconf_dad_timer+0xdb/0xe0
> [  120.119758]  [<c012f8a0>] run_timer_softirq+0x130/0x191
> [  120.133717]  [<c012c06d>] __do_softirq+0x76/0xe4
> [  120.147475]  [<c0106b48>] do_softirq+0x63/0xac
> [  120.147488]  [<c012bff5>] 


> (gdb) list *neigh_create+0x5f
> 0xc03fb397 is in neigh_create (include/linux/slab.h:259).
> 254     /*
> 255      * Shortcuts
> 256      */
> 257     static inline void *kmem_cache_zalloc(struct kmem_cache *k, gfp_t flags)
> 258     {
> 259             return kmem_cache_alloc(k, flags | __GFP_ZERO);
> 260     }

See, networking's kmem_cache_alloc(..., __GFP_ZERO) ended up calling into
the page allocator with __GFP_ZERO.  This is the bug - slab isn't supposed
to do that: the __GFP_ZERO is supposed to be removed.

Now, it's not a highmem page, so prep_zero_page() won't actually establish
a kmap, but it will check that the kmap slot is presently unused on this
CPU.

But networking calls in here from softirq context (illegal for KM_USER0)
and sometimes that KM_USER0 slot *will* be in use, so kmap_atomic_prot()
will go BUG.

I must say it's really really scary that such a low-level function as
prep_zero_page() is using KM_USER0.  I don't think it has enough debugging
checks in there to prevent Bad Stuff from going undetected.

I guess this was the bug:

--- a/mm/slab.c~a
+++ a/mm/slab.c
@@ -2776,7 +2776,7 @@ static int cache_grow(struct kmem_cache 
 	 * 'nodeid'.
 	 */
 	if (!objp)
-		objp = kmem_getpages(cachep, flags, nodeid);
+		objp = kmem_getpages(cachep, local_flags, nodeid);
 	if (!objp)
 		goto failed;
 
_


I don't see why you later got fs corruption - afacit we won't actually
modify the KM_USER0 slot in this scenario.


> 262     /**
> 263      * kzalloc - allocate memory. The memory is set to zero.
> (gdb) list *kmem_cache_alloc+0xa1
> 0xc0172e7a is in kmem_cache_alloc (mm/slab.c:3176).
> 3171                    STATS_INC_ALLOCHIT(cachep);
> 3172                    ac->touched = 1;
> 3173                    objp = ac->entry[--ac->avail];
> 3174            } else {
> 3175                    STATS_INC_ALLOCMISS(cachep);
> 3176                    objp = cache_alloc_refill(cachep, flags);
> 3177            }
> 3178            return objp;
> 3179    }
> 3180
> (gdb) list *cache_alloc_refill+0x380
> 0xc0172872 is in cache_alloc_refill (include/linux/gfp.h:154).
> 149
> 150             /* Unknown node is current node */
> 151             if (nid < 0)
> 152                     nid = numa_node_id();
> 153
> 154             return __alloc_pages(gfp_mask, order,
> 155                     NODE_DATA(nid)->node_zonelists + gfp_zone(gfp_mask));
> 156     }
> 157
> 158     #ifdef CONFIG_NUMA
> (gdb) list *__alloc_pages+0x5b
> 0xc015b7fb is in __alloc_pages (mm/page_alloc.c:1248).
> 1243            if (unlikely(*z == NULL)) {
> 1244                    /* Should this ever happen?? */
> 1245                    return NULL;
> 1246            }
> 1247
> 1248            page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, order,
> 1249                                    zonelist, ALLOC_WMARK_LOW|ALLOC_CPUSET);
> 1250            if (page)
> 1251                    goto got_pg;
> 1252
> (gdb) list *get_page_from_freelist+0x39e
> 0xc015b6e0 is in get_page_from_freelist (include/linux/highmem.h:122).
> 117             return __alloc_zeroed_user_highpage(__GFP_MOVABLE, vma, vaddr);
> 118     }
> 119
> 120     static inline void clear_highpage(struct page *page)
> 121     {
> 122             void *kaddr = kmap_atomic(page, KM_USER0);
> 123             clear_page(kaddr);
> 124             kunmap_atomic(kaddr, KM_USER0);
> 125     }
> 126
> 
> 

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Linus Torvalds]

On Tue, 24 Jul 2007, Andrew Morton wrote:
> 
> I guess this was the bug:

Looks very likely to me. Mike, Alexey, does this fix things for you?

		Linus

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Alexey Dobriyan]

On Tue, Jul 24, 2007 at 11:25:22AM -0700, Linus Torvalds wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> > I guess this was the bug:
>
> Looks very likely to me. Mike, Alexey, does this fix things for you?

Yeah, box is running for more than hour, survived LTP, gdb testsuite,
portage sync and so on.

What new to me is that someone decided TSC is unstable but that's
probably OK on full debug kernel:

	Clocksource tsc unstable (delta = 91724418 ns)
	Time: pit clocksource has been installed.

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Cyrill Gorcunov]

[Alexey Dobriyan - Wed, Jul 25, 2007 at 12:05:28AM +0400]
| On Tue, Jul 24, 2007 at 11:25:22AM -0700, Linus Torvalds wrote:
| > On Tue, 24 Jul 2007, Andrew Morton wrote:
| > > I guess this was the bug:
| >
| > Looks very likely to me. Mike, Alexey, does this fix things for you?
| 
| Yeah, box is running for more than hour, survived LTP, gdb testsuite,
| portage sync and so on.
| 
| What new to me is that someone decided TSC is unstable but that's
| probably OK on full debug kernel:
| 
| 	Clocksource tsc unstable (delta = 91724418 ns)
| 	Time: pit clocksource has been installed.
| 

Hi Alexey,

actualy I've tsc unstabled even with 2.6.21.3 ;)
Someone think that is 'cause of dynamic clock speed
changing

	http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0873.html

		Cyrill

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

[Mike Galbraith]

On Tue, 2007-07-24 at 11:25 -0700, Linus Torvalds wrote:
> 
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> > 
> > I guess this was the bug:
> 
> Looks very likely to me. Mike, Alexey, does this fix things for you?

I don't have very much runtime on it yet, but yes, it seems to have.

	-Mike

SD still better than CFS for 3d \b(was Re: 2.6.23-rc1)

[Kasper Sandberg]

On Sun, 2007-07-22 at 14:04 -0700, Linus Torvalds wrote: 
> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 
> And it has a *ton* of changes as usual for the merge window, way too much 
> for me to be able to post even just the shortlog or diffstat on the 
> mailing list (but I had many people who wanted to full logs to stay 
> around, so you'll continue to see those being uploaded to kernel.org).
> 
> Lots of architecture updates (for just about all of them - x86[-64], arm, 
> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
> (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
> firewire, i2c, you name it).
> 
> Filesystems, VM, networking, ACPI, it's all there. And virtualization all 
> over the place (kvm, lguest, Xen).
> 
> Notable new things might be the merge of the cfs scheduler, and the UIO 
> driver infrastructure might interest some people.

Im still not so keen about this, Ingo never did get CFS to match SD in
smoothness for 3d applications, where my test subjects are quake(s),
world of warcraft via wine, unreal tournament 2004. And this is despite
many patches he sent me to try and tweak it. As far as im concerned, i
may be forced to unofficially maintain SD for my own systems(allthough
lots in the gaming community is bound to be interrested, as it does make
games lots better)


<snip>

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Kasper Sandberg <lkml@metanurb.dk> wrote:

> Im still not so keen about this, Ingo never did get CFS to match SD in 
> smoothness for 3d applications, where my test subjects are quake(s), 
> world of warcraft via wine, unreal tournament 2004. [...]

here's an update: checking whether Wine could be a factor in your 
problem i just tested latest CFS against latest SD with a 3D game 
running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the
most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). 
Here are the results in a pretty graph:

   http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg

or, in text:

         2.6.22-ck1                         2.6.22-cfs-v19
   ------------------------            ------------------------
   quake + 0 loops | 41 fps            quake + 0 loops | 41 fps
   quake + 1 loop  |  3 fps            quake + 1 loop  | 41 fps
   quake + 2 loops |  2 fps            quake + 2 loops | 32 fps
   quake + 3 loops |  1 fps            quake + 3 loops | 24 fps
   quake + 4 loops |  0 fps            quake + 4 loops | 20 fps
   quake + 5 loops |  0 fps            quake + 5 loops | 16 fps

Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively 
during any kind of load. The game is completely unusable with 1 CPU loop 
running already!

Quake3-under-Wine behavior under CFS: framerate goes down gently with 
load, gameplay remains smooth. Framerate is still pretty acceptable and 
the game is playable even with a 500% CPU overload. The graph looks good 
and the framerate reduction goes roughly along the expected 1/n 
'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps 
its fully 41 fps even with 1 competing loop running on the CPU due to 
"sleeper fairness".]

[ i've re-tested this using other SD and ck versions and other CFS 
  versions such as v2.6.23-rc1 and the results are the same. To get the 
  fps result i started a simple game scene: Single Player /
  Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not 
  move the player at all, just looked at the framerate that is 
  displayed. (i also tried other scenes and other gameplay sections and 
  they all behave consistently with the above results.) The system was
  otherwise completely idle. While i trust these numbers take them with 
  a grain of salt, i'm obviously not neutral in this thing :-) ]

so Kasper, i'll definitely need your help in tracking down your 3D 
smoothness problem under CFS. I have the feeling that it could be some 
odd factor that only hits your system, and once we've tracked that down 
there will be a simple solution that does not affect the totality of the 
scheduler. So far only you have reported any 3D game smoothness problem 
against recent CFS versions. (all 3D feedback has been positive, and 
that includes a number of gamers as well. Most of the 3D smoothness 
problems were fixed in CFS v13..v15 and it has not been reported to have 
regressed since then.)

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* John <darknessenvelops@gmail.com> wrote:

> Ingo-
> 
> Why not perform the same test using the native linux Q3 client to 
> compare numbers to wine? [...]

I regularly test native Linux games on CFS, and they all behave well. 
While waiting for more detailed data from Kasper i was looking for 
atypical stuff in Kasper's description about what his workload involves, 
and what looked a bit atypical was that Kasper's workload also involved 
gaming under Wine:

> > > my test subjects are quake(s), world of warcraft via wine, unreal 
> > > tournament 2004. [...]

and Wine is a more complex server/client scenario instead of a single 
(and simple) standalone Quake3 binary that the Linux binary does. So it 
looked more interesting from a scheduler workload (and scheduler 
regression) POV. In any case i'll need more info from Kasper.

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 7/30/07, John <darknessenvelops@gmail.com> wrote:
> I understand that, I was just wondering if the FPS scales the same natively
> vs. Wine as I typically only run native games.  I have been hesitant to move
> over to CFS due to reports of 3D issues and wanted to see if you had numbers
> in regards to CFS vs. SD.

John, the numbers Ingo makes and the numbers you make will no doubt be
different (unless by some fantastic freak of nature you both have
identical systems).  Take this opportunity to do this testing yourself
so in case there is some improvement to make, it can be done for
2.6.23.  Nobody can benchmark your system but you.

Remember to set CONFIG_HZ to 1000

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* John <darknessenvelops@gmail.com> wrote:

> On 7/29/07, Ingo Molnar <mingo@elte.hu> wrote:
> >
> >
> > * John <darknessenvelops@gmail.com> wrote:
> >
> > > Ingo-
> > >
> > > Why not perform the same test using the native linux Q3 client to
> > > compare numbers to wine? [...]
> >
> > I regularly test native Linux games on CFS, and they all behave well.
> > While waiting for more detailed data from Kasper i was looking for
> > atypical stuff in Kasper's description about what his workload involves,
> > and what looked a bit atypical was that Kasper's workload also involved
> > gaming under Wine:
>
> I understand that, I was just wondering if the FPS scales the same 
> natively vs. Wine as I typically only run native games.  [...]

people are regularly testing 3D smoothness, and they find CFS good 
enough:

   http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html

and that matches my experience as well (as limited as it may be). In 
general my impression is that CFS and SD are roughly on par when it 
comes to 3D smoothness.

The Wine+Quake3 numbers i posted yesterday are so bad under SD that they 
must be some artifact in SD (possibly related to yield - i've strace-ed 
the tasks under SD today and they are blocking in yield), so they are 
not really representative of the general quality of SD (unless you are 
being hit by that particular regression). Still it is kind of ironic 
that when i tried to find a 3D regression in CFS i found a 3D regression 
in SD.

What is more interesting (to me) is not the positive CFS feedback but 
negative CFS feedback (although positive feedback certain _feels_ good 
so dont hold it back intentionally ;-), and i cannot possibly give you 
any definitive answer: at this point CFS could still have artifacts and 
bugs, so "check and see yourself" is the best answer. All i can tell you 
is that there are no open 3D related regressions for CFS at the moment.

> [...] I have been hesitant to move over to CFS due to reports of 3D 
> issues and wanted to see if you had numbers in regards to CFS vs. SD.

i have no numbers now, other than the trivial native 'ppracer' game 
where SD and CFS have roughly the same framerate under load:

     SD           CFS
   0: 38.1      0: 38.1
   1: 24.0      1: 24.2
   2: 16.6      2: 16.1
   3: 11.9      3: 12.3
   4:  9.9      4:  9.7
   5:  8.2      5:  8.1

which i'd have expected, ppracer is quite CPU-intense on my test-system, 
and the fairness model of SD and CFS is similar for CPU-bound tasks.

But ... numbers from _me_ are suspect by definition, i wrote a good 
chunk of the CFS code :-) So it would be much more interesting if others 
provided more numbers.

Would you be interested in trying CFS and doing some numers perhaps? It 
requires some work: you have to start up your favorite game in a way 
that gives a reliable framerate number. (many games allow the display of 
FPS in-game) In Quake3 i simply started the game and did not move the 
player - that is something easy to reproduce.

then create load the following way, by entering this into a shell:

  while :; do :; done &

that will cause a shell to just loop infinitely, hogging the CPU. This 
is the "1 loop" case in the numbers i posted. Start several of them to 
get more. (Type 'killall bash' in the same terminal to get rid of them.) 
Monitor how the FPS of your game changes when you start more and more 
CPU hogs, and note the numbers. Repeat it under SD and CFS as well, and 
please post the results into this thread.

and note that CPU hogs are just one type of 'load' that a system can 
experience - IO load or networking load could impact your in-game 
experience just as much.

If you see any artifact or FPS reduction under CFS i'll give you further 
info about how to debug it (were you interested in debugging it).

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Miguel Figueiredo]

Em Segunda, 30 de Julho de 2007 12:46, Ingo Molnar escreveu:
> * John <darknessenvelops@gmail.com> wrote:
> > On 7/29/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > * John <darknessenvelops@gmail.com> wrote:
> > > > Ingo-
> > > >
> > > > Why not perform the same test using the native linux Q3 client to
> > > > compare numbers to wine? [...]


[...]

> and that matches my experience as well (as limited as it may be). In
> general my impression is that CFS and SD are roughly on par when it
> comes to 3D smoothness.
>
> The Wine+Quake3 numbers i posted yesterday are so bad under SD that they
> must be some artifact in SD (possibly related to yield - i've strace-ed
> the tasks under SD today and they are blocking in yield), so they are
> not really representative of the general quality of SD (unless you are
> being hit by that particular regression). Still it is kind of ironic
> that when i tried to find a 3D regression in CFS i found a 3D regression
> in SD.

I also tryied Q3A demo and i got similar values to yours:

CFS		90
2.6.22	90
SD		90

while running that endless loop, on 2.6.22 and SD it drops instantly to 4 fps.
While CFS runs ~70 with 1.9 load. I was able to play the game without noticing 
much degradation. I written these values while playing under CFS:

load fps
1.66	81
1.73	75
1.97	70s


With this patch [1] someone sent me over IRC i get similar values to CFS, 
maybe a few fps more, but thats insignificant and not very accurate to 
measure. Anyway with this patch i am playing with a load of 2.2 at ~75 fps, 
1024x768 windowed. It's enjoyable to frag the dumb 'Major'  as under CFS. 


I think the main difference in performance of CFS and SD it's the 
implementation of sched_yield (which is used by graphic drivers) and CFS has 
changed the implementation of sched_yield. You use:

in mainline (2.6.22): 
/**
 * sys_sched_yield - yield the current processor to other threads.
 *
 * This function yields the current CPU by moving the calling thread
 * to the expired array. If there are no other threads running on this
 * CPU then this function will return.
 */

you changed it to something like:

if (unlikely(rq->nr_running == 1))
                schedstat_inc(rq, yld_act_empty);
        else
                current->sched_class->yield_task(rq, current);


wile mainline (2.6.22) and SD use:

dequeue_task(current, array);
enqueue_task(current, target);

and

requeue_task()


Anyway i am going to continue to frag a bit more :)


[1] - http://rafb.net/p/Rbpqaz26.html
There are 2 modes for this hack:
sysctl kernel.sched_yield = 1 or 2, see patch.


[...]

>
> 	Ingo
> _______________________________________________
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: ck@vds.kolivas.org
> http://vds.kolivas.org/mailman/listinfo/ck

-- 

Com os melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Miguel Figueiredo <elmig@debianpt.org> wrote:

> in mainline (2.6.22): 
> /**
>  * sys_sched_yield - yield the current processor to other threads.
>  *
>  * This function yields the current CPU by moving the calling thread
>  * to the expired array. If there are no other threads running on this
>  * CPU then this function will return.
>  */
> 
> you changed it to something like:
> 
> if (unlikely(rq->nr_running == 1))
>                 schedstat_inc(rq, yld_act_empty);
>         else
>                 current->sched_class->yield_task(rq, current);
>
> wile mainline (2.6.22) and SD use:
> 
> dequeue_task(current, array);
> enqueue_task(current, target);

this is what CFS does:

  static void yield_task_fair(struct rq *rq, struct task_struct *p)
  {
          struct cfs_rq *cfs_rq = task_cfs_rq(p);
          u64 now = __rq_clock(rq);

          /*
           * Dequeue and enqueue the task to update its
           * position within the tree:
           */
          dequeue_entity(cfs_rq, &p->se, 0, now);
          enqueue_entity(cfs_rq, &p->se, 0, now);
  }

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Miguel Figueiredo]

Em Segunda, 30 de Julho de 2007 19:38, Ingo Molnar escreveu:
> * Miguel Figueiredo <elmig@debianpt.org> wrote:
> > in mainline (2.6.22):
> > /**
> >  * sys_sched_yield - yield the current processor to other threads.
> >  *
> >  * This function yields the current CPU by moving the calling thread
> >  * to the expired array. If there are no other threads running on this
> >  * CPU then this function will return.
> >  */
> >

[...]

> this is what CFS does:
>
>   static void yield_task_fair(struct rq *rq, struct task_struct *p)
>   {
>           struct cfs_rq *cfs_rq = task_cfs_rq(p);
>           u64 now = __rq_clock(rq);
>
>           /*
>            * Dequeue and enqueue the task to update its
>            * position within the tree:
>            */
>           dequeue_entity(cfs_rq, &p->se, 0, now);
>           enqueue_entity(cfs_rq, &p->se, 0, now);
>   }
>
> 	Ingo

So the difference from mainline (2.6.22) is that now you removed 
requeue_task(), is that it?
-- 

Com os melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Miguel Figueiredo <elmig@debianpt.org> wrote:

> > this is what CFS does:
> >
> >   static void yield_task_fair(struct rq *rq, struct task_struct *p)
> >   {
> >           struct cfs_rq *cfs_rq = task_cfs_rq(p);
> >           u64 now = __rq_clock(rq);
> >
> >           /*
> >            * Dequeue and enqueue the task to update its
> >            * position within the tree:
> >            */
> >           dequeue_entity(cfs_rq, &p->se, 0, now);
> >           enqueue_entity(cfs_rq, &p->se, 0, now);
> >   }
> >
> > 	Ingo
> 
> So the difference from mainline (2.6.22) is that now you removed 
> requeue_task(), is that it?

No - I renamed requeue_task() to current->sched_class->yield_task(), 
which does this for SCHED_OTHER:

           /*
            * Dequeue and enqueue the task to update its
            * position within the tree:
            */
           dequeue_entity(cfs_rq, &p->se, 0, now);
           enqueue_entity(cfs_rq, &p->se, 0, now);

and this for RT tasks:

           static void
           yield_task_rt(struct rq *rq, struct task_struct *p)
           {
                   requeue_task_rt(rq, p);
           }

a dequeue+enqueue _is_ a requeue ...

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[david]

On Mon, 30 Jul 2007, Ingo Molnar wrote:

> * John <darknessenvelops@gmail.com> wrote:
>
>> On 7/29/07, Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>>
>>> * John <darknessenvelops@gmail.com> wrote:
>>>
>>>> Ingo-
>>>>
>>>> Why not perform the same test using the native linux Q3 client to
>>>> compare numbers to wine? [...]
>>>
>>> I regularly test native Linux games on CFS, and they all behave well.
>>> While waiting for more detailed data from Kasper i was looking for
>>> atypical stuff in Kasper's description about what his workload involves,
>>> and what looked a bit atypical was that Kasper's workload also involved
>>> gaming under Wine:
>>
>> I understand that, I was just wondering if the FPS scales the same
>> natively vs. Wine as I typically only run native games.  [...]
>
> people are regularly testing 3D smoothness, and they find CFS good
> enough:
>
>   http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html
>
> and that matches my experience as well (as limited as it may be). In
> general my impression is that CFS and SD are roughly on par when it
> comes to 3D smoothness.
<SNIP>
> i have no numbers now, other than the trivial native 'ppracer' game
> where SD and CFS have roughly the same framerate under load:
>
>     SD           CFS
<SNIP>
> which i'd have expected, ppracer is quite CPU-intense on my test-system,
> and the fairness model of SD and CFS is similar for CPU-bound tasks.
>
> But ... numbers from _me_ are suspect by definition, i wrote a good
> chunk of the CFS code :-) So it would be much more interesting if others
> provided more numbers.
>
> Would you be interested in trying CFS and doing some numers perhaps? It
> requires some work: you have to start up your favorite game in a way
> that gives a reliable framerate number. (many games allow the display of
> FPS in-game) In Quake3 i simply started the game and did not move the
> player - that is something easy to reproduce.

the one report that I saw said that the FPS numbers were overall the same, 
but what the reporter was seeing was that CFS was doing it in bursts of 
activity while SD was smoother. this wasn't enough to show up in the fps 
numbers being reported, but was enough to be unreasonable for gameing.

IIRC Linus responded with thoughts on granularity and the fact that 
changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 
10x (which could be enough to trigger this sort of issue)

David Lang

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* david@lang.hm <david@lang.hm> wrote:

> > Would you be interested in trying CFS and doing some numers perhaps? 
> > It requires some work: you have to start up your favorite game in a 
> > way that gives a reliable framerate number. (many games allow the 
> > display of FPS in-game) In Quake3 i simply started the game and did 
> > not move the player - that is something easy to reproduce.
> 
> the one report that I saw said that the FPS numbers were overall the 
> same, but what the reporter was seeing was that CFS was doing it in 
> bursts of activity while SD was smoother. [...]

which report is that, precisely? I'm not aware of any such report past 
CFS v14 or so.

> IIRC Linus responded with thoughts on granularity and the fact that 
> changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 
> 10x (which could be enough to trigger this sort of issue)

ah, you mean Kasper Sandberg's report? That turned out to be based on an 
older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, 
and if there's still any regression left we'll fix it.

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[david]

On Mon, 30 Jul 2007, Ingo Molnar wrote:

> * david@lang.hm <david@lang.hm> wrote:
>
>>> Would you be interested in trying CFS and doing some numers perhaps?
>>> It requires some work: you have to start up your favorite game in a
>>> way that gives a reliable framerate number. (many games allow the
>>> display of FPS in-game) In Quake3 i simply started the game and did
>>> not move the player - that is something easy to reproduce.
>>
>> the one report that I saw said that the FPS numbers were overall the
>> same, but what the reporter was seeing was that CFS was doing it in
>> bursts of activity while SD was smoother. [...]
>
> which report is that, precisely? I'm not aware of any such report past
> CFS v14 or so.
>
>> IIRC Linus responded with thoughts on granularity and the fact that
>> changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by
>> 10x (which could be enough to trigger this sort of issue)
>
> ah, you mean Kasper Sandberg's report? That turned out to be based on an
> older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests,
> and if there's still any regression left we'll fix it.

probably. I delete lkml messages pretty agressivly so I don't have them 
around to refer to.

David Lang

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* david@lang.hm <david@lang.hm> wrote:

> > ah, you mean Kasper Sandberg's report? That turned out to be based 
> > on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his 
> > tests, and if there's still any regression left we'll fix it.
> 
> probably. I delete lkml messages pretty agressivly so I don't have 
> them around to refer to.

lkml.org is your friend:

 http://lkml.org/lkml/2007/7/27/423
 http://lkml.org/lkml/2007/7/28/50
 http://lkml.org/lkml/2007/7/30/195

:-)

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 7/31/07, Jacob Braun <jwbraun@gmail.com> wrote:
> On 7/30/07, kriko <kristjan.ugrin@gmail.com> wrote:
> > I would try the new cfs how it performs, but it seems that nvidia drivers
> > doesn't compile successfully under 2.6.23-rc1.
> > http://files.myopera.com/kriko/files/nvidia-installer.log
> >
> > If someone has the solution, please share.
>
> There is a patch for the nvidia drivers here:
> http://bugs.gentoo.org/attachment.cgi?id=125959

The ATI drivers (current 8.39.4) were broken by
commit e21ea246bce5bb93dd822de420172ec280aed492
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>

Bad call on the "nobody was using these", Martin :(

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Peter Zijlstra]

On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote:
> On 7/31/07, Jacob Braun <jwbraun@gmail.com> wrote:
> > On 7/30/07, kriko <kristjan.ugrin@gmail.com> wrote:
> > > I would try the new cfs how it performs, but it seems that nvidia drivers
> > > doesn't compile successfully under 2.6.23-rc1.
> > > http://files.myopera.com/kriko/files/nvidia-installer.log
> > >
> > > If someone has the solution, please share.
> >
> > There is a patch for the nvidia drivers here:
> > http://bugs.gentoo.org/attachment.cgi?id=125959
> 
> The ATI drivers (current 8.39.4) were broken by
> commit e21ea246bce5bb93dd822de420172ec280aed492
> Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
> 
> Bad call on the "nobody was using these", Martin :(

Nobody in the upstream kernel did, and that is what matters. If you care
about your kernel code get it upstream.

As for breaking binary crap, thats a bonus. Break them hard, break them
often.

Kudos to Martin.

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kyle Rose]

> As for breaking binary crap, thats a bonus. Break them hard, break them
> often.
>   
I think there's a big difference in philosophy between "break binary
drivers if you want to make a legitimate change for whatever reason" and
"break binary drivers just to be a pain in the ass to the developers and
users of said drivers."  I think most people here agree with the first.
It's unclear to me how many here agree with the second, but I know it's
at least one. ;-)

Kyle

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Martin Schwidefsky]

On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote:
> On 7/31/07, Jacob Braun <jwbraun@gmail.com> wrote:
> > On 7/30/07, kriko <kristjan.ugrin@gmail.com> wrote:
> > > I would try the new cfs how it performs, but it seems that nvidia drivers
> > > doesn't compile successfully under 2.6.23-rc1.
> > > http://files.myopera.com/kriko/files/nvidia-installer.log
> > >
> > > If someone has the solution, please share.
> >
> > There is a patch for the nvidia drivers here:
> > http://bugs.gentoo.org/attachment.cgi?id=125959
> 
> The ATI drivers (current 8.39.4) were broken by
> commit e21ea246bce5bb93dd822de420172ec280aed492
> Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
> 
> Bad call on the "nobody was using these", Martin :(

Do we care ? The code should be replaced with ptep_get_and_clear +
pte_modify anyway..

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Rashkae]

Martin Schwidefsky wrote:

> 
> Do we care ? The code should be replaced with ptep_get_and_clear +
> pte_modify anyway..
> 

Since the general direction of this thread was for people to test 3D 
game performance with the shiny new CFS cpu scheduler, I would say yes, 
we do care if people with the only 2 types of gaming caliber Video cards 
can get said video cards working, right now, with said shiny new kernel.

Yes yes, I know, kernel devs don't care if they break binary drivers... 
and in principle, I agree with that philosophy.. but it's still damn 
inconvenient at times :)

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Arjan van de Ven]

On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote:
> On 7/31/07, Jacob Braun <jwbraun@gmail.com> wrote:
> > On 7/30/07, kriko <kristjan.ugrin@gmail.com> wrote:
> > > I would try the new cfs how it performs, but it seems that nvidia drivers
> > > doesn't compile successfully under 2.6.23-rc1.
> > > http://files.myopera.com/kriko/files/nvidia-installer.log
> > >
> > > If someone has the solution, please share.
> >
> > There is a patch for the nvidia drivers here:
> > http://bugs.gentoo.org/attachment.cgi?id=125959
> 
> The ATI drivers (current 8.39.4) were broken by
> commit e21ea246bce5bb93dd822de420172ec280aed492
> Author: Martin Schwidefsky <schwidefsky@de.ibm.com>


some fo these binary drivers do really really bad stuff (esp the AMD
ones are infamous for that) and it's no surprise they might throw of a
new scheduler. In fact, that's a bonus, some of those hacks are
workarounds for older (often 2.4) scheduler corner cases and should just
be removed from the driver to get better performance. Holding back linux
for such hacky junk in binary drivers would be the absolute worst thing
to do; even for people who insist on using these drivers over the open
source ones, since the next rev of these drivers can now use the new
scheduler and actually be faster with all the workarounds removed.

Very likely the best thing to do is to contact the supplier of the
driver (AMD or Nvidia) and ask them to fix it.....

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Christoph Hellwig]

On Tue, Jul 31, 2007 at 02:25:47AM +1000, Matthew Hawkins wrote:
> 
> The ATI drivers (current 8.39.4) were broken by
> commit e21ea246bce5bb93dd822de420172ec280aed492
> Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
> 
> Bad call on the "nobody was using these", Martin :(

Sorry to use foul language once again after a while, but:

	Fuck you Martin!

not only is complaining about illegal binary crap totally offtopic
on this list, and making youself a fool for using that piece of shit
is annoying enough, but don't even try to badmouth Martin for doing
important and needed cleanups.  And now get out of here!

Re: [ck] Re: SD still better than CFS for 3d ?

[Roland Dreier]

 > 	Fuck you Martin!

I think you meant to yell at Matthew, not Martin ;)

 - R.

Re: [ck] Re: SD still better than CFS for 3d ?

[Christoph Hellwig]

On Mon, Jul 30, 2007 at 12:53:41PM -0700, Roland Dreier wrote:
>  > 	Fuck you Martin!
> 
> I think you meant to yell at Matthew, not Martin ;)

Yes, of course :)  Also thanks to all the people pointing that out
in private.

Re: [ck] Re: SD still better than CFS for 3d ?

[Matthew Hawkins]

On 7/31/07, Roland Dreier <rdreier@cisco.com> wrote:
>  >      Fuck you Martin!
>
> I think you meant to yell at Matthew, not Martin ;)

What's amusing about this is he's yelling at me for something I didn't
do, can't even get my name right, and has the audacity to claim that
*I* am the one looking like a fool!  While we're descending into
primary school theatrics, may I just say "takes one to know one" ;-)

I took the time to track down what caused a breakage - in an "illegal
binary driver" (not against the law here, though defamation certainly
is...) no less.  And contacted the vendor (separately).  Other people
on desktop machines with an ATI card using the fglrx driver may have
been interested to know that they can't do the benchmarking some
people here on lkml and -mm are asking for with a current 2.6.23 git
kernel, hence my post.

Martin's cleanup patch is good and I never claimed otherwise, I just
said the comment on the commit was a bad call (as there are users of
that interface).  Certainly ATI should fix their dodgy drivers.
That's been the cry of the community for a long time...

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?

[Martin Schwidefsky]

On Tue, 2007-07-31 at 13:07 +1000, Matthew Hawkins wrote:
> On 7/31/07, Roland Dreier <rdreier@cisco.com> wrote:
> >  >      Fuck you Martin!
> >
> > I think you meant to yell at Matthew, not Martin ;)
> 
> What's amusing about this is he's yelling at me for something I didn't
> do, can't even get my name right, and has the audacity to claim that
> *I* am the one looking like a fool!  While we're descending into
> primary school theatrics, may I just say "takes one to know one" ;-)

Pouring oil into the fire ?

> I took the time to track down what caused a breakage - in an "illegal
> binary driver" (not against the law here, though defamation certainly
> is...) no less.  And contacted the vendor (separately).  Other people
> on desktop machines with an ATI card using the fglrx driver may have
> been interested to know that they can't do the benchmarking some
> people here on lkml and -mm are asking for with a current 2.6.23 git
> kernel, hence my post.

To inform the vendor and to post a warning about the issue on lkml was
the right thing to do. It is the wording of your post that obviously
irked some people.

> Martin's cleanup patch is good and I never claimed otherwise, I just
> said the comment on the commit was a bad call (as there are users of
> that interface).  Certainly ATI should fix their dodgy drivers.
> That's been the cry of the community for a long time...

The commit message could have been better. The correct thing to say
would have been "Nobody in the official kernel is using
ptep_test_and_clear_dirty and ptep_clear_flush_dirty."
nvidia will have to adapt their binary driver. This is not the first
time it breaks and it won't be the last time. We do not really have a
problem and we should all calm down and put that issue to rest.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.

Re: [ck] Re: SD still better than CFS for 3d ?

[Christoph Hellwig]

Matthew, odd off.  ait binary crap is totally offtopic here on the list,
and beeing prude for beeing a fuckhead and holding development back doesn't
exactly helpe either.  Go back to your -ck fanboy land and shut up now.

Re: [ck] Re: SD still better than CFS for 3d ?

[Adrian Bunk]

On Tue, Jul 31, 2007 at 01:07:30PM +1000, Matthew Hawkins wrote:
>...
> I took the time to track down what caused a breakage - in an "illegal
> binary driver" (not against the law here, though defamation certainly
> is...) no less.  And contacted the vendor (separately).  Other people
> on desktop machines with an ATI card using the fglrx driver may have
> been interested to know that they can't do the benchmarking some
> people here on lkml and -mm are asking for with a current 2.6.23 git
> kernel, hence my post.
>...

But there's not much value in benchmarking if an important part of the 
performance critical code is in some undebuggable driver...

> Matt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [ck] Re: SD still better than CFS for 3d ?

[Matthew Hawkins]

On 8/1/07, Adrian Bunk <bunk@stusta.de> wrote:
> But there's not much value in benchmarking if an important part of the
> performance critical code is in some undebuggable driver...

In this case we don't care about the performance of the video driver.
This isn't a race to see who can get the most fps.  The driver can be
thought of as a black box so long as comparative benchmarks are done
with the same driver.

What we're looking for primarily is progress or regress in
interactivity under load with different cpu schedulers, and secondly
the effect of swap prefetch.  The video driver is irrelevant -
especially considering the people doing this testing have a wide
variety of video cards.  This is why I have included some commentary
on "feel" because that's the important part.

Ingo specifically asked for CFS v20 in 2.6.23 to be included in the
testing (its not available separately on his website), hence the need
to be able to bring up one's usual working environment under that
kernel also so the results aren't skewed by driver artifacts.

For my next trick, I'll attempt to quantify the "feel" bits using
scheduler statistics.
While riding a unicycle.

Okay, scratch the unicycle ;-)

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?

[Adrian Bunk]

On Wed, Aug 01, 2007 at 04:19:36PM +1000, Matthew Hawkins wrote:
> On 8/1/07, Adrian Bunk <bunk@stusta.de> wrote:
> > But there's not much value in benchmarking if an important part of the
> > performance critical code is in some undebuggable driver...
> 
> In this case we don't care about the performance of the video driver.
> This isn't a race to see who can get the most fps.  The driver can be
> thought of as a black box so long as comparative benchmarks are done
> with the same driver.
>...

What if your "black box" e.g. uses the BKL?

> Matt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kenneth Prugh]

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

Ingo Molnar wrote:
> <large snip>

Hello, I have a gaming rig and would love to help benchmark with my copy
of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else
that would better serve as a benchmark I could grab it and try.

The only problem is I don't know what 2 kernels I should be using to
test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD?

-- 
Kenneth Prugh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Kenneth Prugh <ken69267@gmail.com> wrote:

> Ingo Molnar wrote:
> > <large snip>
> 
> Hello, I have a gaming rig and would love to help benchmark with my 
> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have 
> anything else that would better serve as a benchmark I could grab it 
> and try.
> 
> The only problem is I don't know what 2 kernels I should be using to 
> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD?

.22-ck1 includes it, so that should be fine:

 http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kenneth Prugh]

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

Ingo Molnar wrote:
> * Kenneth Prugh <ken69267@gmail.com> wrote:
> 
>> Ingo Molnar wrote:
>>> <large snip>
>> Hello, I have a gaming rig and would love to help benchmark with my 
>> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have 
>> anything else that would better serve as a benchmark I could grab it 
>> and try.
>>
>> The only problem is I don't know what 2 kernels I should be using to 
>> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD?
> 
> .22-ck1 includes it, so that should be fine:
> 
>  http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html
> 
> 	Ingo
> 

Alright, Just got done with some testing of UT2004 between 2.6.23-rc1
CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map
while not moving at all and always facing the same direction, while
slowing increasing the number of loops.

CFS generally seemed a lot smoother as the load increased, while SD
broke down to a highly unstable fps count that fluctuated massively
around the third loop. Seems like I will stick to CFS for gaming now.

Below you will find the results of my test with the average number of FPS.

		CFS		|		SD
UT2004 + 0 loops | 200 FPS		UT2004 + 0 loops | 190 FPS
UT2004 + 1 loops | 195 FPS		UT2004 + 1 loops | 190 FPS
UT2004 + 2 loops | 190 FPS		UT2004 + 2 loops | 190 FPS
UT2004 + 3 loops | 189 FPS		UT2004 + 3 loops | 136 FPS
UT2004 + 4 loops | 150 FPS		UT2004 + 4 loops | 137 FPS
UT2004 + 5 loops | 145 FPS		UT2004 + 5 loops | 136 FPS
UT2004 + 6 loops | 145 FPS		UT2004 + 6 loops | 105 FPS
UT2004 + 7 loops | 118 FPS		UT2004 + 7 loops | 104 FPS
UT2004 + 8 loops | 97 FPS		UT2004 + 8 loops | 104 FPS
UT2004 + 9 loops | 94 FPS		UT2004 + 9 loops | 89 FPS
UT2004 + 10 loops | 92 FPS		UT2004 + 10 loops | 91 FPS

-- 
Kenneth Prugh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Miguel Figueiredo]

Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu:
> Ingo Molnar wrote:
> > * Kenneth Prugh <ken69267@gmail.com> wrote:
> >> Ingo Molnar wrote:
> >>> <large snip>
> >>
> >> Hello, I have a gaming rig and would love to help benchmark with my
> >> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have
> >> anything else that would better serve as a benchmark I could grab it
> >> and try.
> >>
> >> The only problem is I don't know what 2 kernels I should be using to
> >> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD?
> >
> > .22-ck1 includes it, so that should be fine:
> >
> >  http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html
> >
> > 	Ingo
>
> Alright, Just got done with some testing of UT2004 between 2.6.23-rc1
> CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map
> while not moving at all and always facing the same direction, while
> slowing increasing the number of loops.
>
> CFS generally seemed a lot smoother as the load increased, while SD
> broke down to a highly unstable fps count that fluctuated massively
> around the third loop. Seems like I will stick to CFS for gaming now.
>
> Below you will find the results of my test with the average number of FPS.
>
> 		CFS		|		SD
> UT2004 + 0 loops | 200 FPS		UT2004 + 0 loops | 190 FPS
> UT2004 + 1 loops | 195 FPS		UT2004 + 1 loops | 190 FPS
> UT2004 + 2 loops | 190 FPS		UT2004 + 2 loops | 190 FPS
> UT2004 + 3 loops | 189 FPS		UT2004 + 3 loops | 136 FPS
> UT2004 + 4 loops | 150 FPS		UT2004 + 4 loops | 137 FPS
> UT2004 + 5 loops | 145 FPS		UT2004 + 5 loops | 136 FPS
> UT2004 + 6 loops | 145 FPS		UT2004 + 6 loops | 105 FPS
> UT2004 + 7 loops | 118 FPS		UT2004 + 7 loops | 104 FPS
> UT2004 + 8 loops | 97 FPS		UT2004 + 8 loops | 104 FPS
> UT2004 + 9 loops | 94 FPS		UT2004 + 9 loops | 89 FPS
> UT2004 + 10 loops | 92 FPS		UT2004 + 10 loops | 91 FPS

can you apply the patch [1] that changes the behaviour of sched_yield on SD 
and report the results?

SD should scale a lot better after the patch.

1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html

-- 

Com os melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kenneth Prugh]

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

Miguel Figueiredo wrote:
> Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu:
>> Ingo Molnar wrote:
>>> * Kenneth Prugh <ken69267@gmail.com> wrote:
>>>> Ingo Molnar wrote:
>>>>> <large snip>
>>>> Hello, I have a gaming rig and would love to help benchmark with my
>>>> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have
>>>> anything else that would better serve as a benchmark I could grab it
>>>> and try.
>>>>
>>>> The only problem is I don't know what 2 kernels I should be using to
>>>> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD?
>>> .22-ck1 includes it, so that should be fine:
>>>
>>>  http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html
>>>
>>> 	Ingo
>> Alright, Just got done with some testing of UT2004 between 2.6.23-rc1
>> CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map
>> while not moving at all and always facing the same direction, while
>> slowing increasing the number of loops.
>>
>> CFS generally seemed a lot smoother as the load increased, while SD
>> broke down to a highly unstable fps count that fluctuated massively
>> around the third loop. Seems like I will stick to CFS for gaming now.
>>
>> Below you will find the results of my test with the average number of FPS.
>>
>> 		CFS		|		SD
>> UT2004 + 0 loops | 200 FPS		UT2004 + 0 loops | 190 FPS
>> UT2004 + 1 loops | 195 FPS		UT2004 + 1 loops | 190 FPS
>> UT2004 + 2 loops | 190 FPS		UT2004 + 2 loops | 190 FPS
>> UT2004 + 3 loops | 189 FPS		UT2004 + 3 loops | 136 FPS
>> UT2004 + 4 loops | 150 FPS		UT2004 + 4 loops | 137 FPS
>> UT2004 + 5 loops | 145 FPS		UT2004 + 5 loops | 136 FPS
>> UT2004 + 6 loops | 145 FPS		UT2004 + 6 loops | 105 FPS
>> UT2004 + 7 loops | 118 FPS		UT2004 + 7 loops | 104 FPS
>> UT2004 + 8 loops | 97 FPS		UT2004 + 8 loops | 104 FPS
>> UT2004 + 9 loops | 94 FPS		UT2004 + 9 loops | 89 FPS
>> UT2004 + 10 loops | 92 FPS		UT2004 + 10 loops | 91 FPS
> 
> can you apply the patch [1] that changes the behaviour of sched_yield on SD 
> and report the results?
> 
> SD should scale a lot better after the patch.
> 
> 1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html
> 

I Applied the patch. SD Seemed a bit smoother over the loads, although
that could be a placebo effect. It wasn't until the 8 or 9th loop
running that I could really notice that the fps were fluctuating in the
map without looking at the fps counter.

SD-Patched

UT2004 + 0 loops | 202 FPS
UT2004 + 1 loops | 201 FPS
UT2004 + 2 loops | 199 FPS
UT2004 + 3 loops | 143 FPS
UT2004 + 4 loops | 145 FPS
UT2004 + 5 loops | 145 FPS
UT2004 + 6 loops | 112 FPS
UT2004 + 7 loops | 110 FPS
UT2004 + 8 loops | 108 FPS
UT2004 + 9 loops | 90 FPS
UT2004 + 10 loops | 89 FPS

-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Kenneth Prugh <ken69267@gmail.com> wrote:

> Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 
> CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a 
> map while not moving at all and always facing the same direction, 
> while slowing increasing the number of loops.
> 
> CFS generally seemed a lot smoother as the load increased, while SD 
> broke down to a highly unstable fps count that fluctuated massively 
> around the third loop. Seems like I will stick to CFS for gaming now.
> 
> Below you will find the results of my test with the average number of 
> FPS.

Thanks Kenneth for the testing! I've created a graph out of your 
numbers:

  http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg

(it also includes the SD numbers you got with the turn-yield-into-NOP 
hack applied.)

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> * Kenneth Prugh <ken69267@gmail.com> wrote:
> > CFS generally seemed a lot smoother as the load increased, while SD
> > broke down to a highly unstable fps count that fluctuated massively
> > around the third loop. Seems like I will stick to CFS for gaming now.

My experience was quite similar.  I noticed after launching the second
loop that the FPS stuck down to 15 for about 20 seconds, then climbed
back up to 48.  After that it went rapidly downhill.  This is similar
to other benchmarks I've done of SD versus CFS in the past.  At a
"normal" load they're fairly similar but SD breaks down under
pressure.
The only other thing of interest is that the -ck kernel had the WM
menus appear in about 3 seconds rather than 5-8 under the other two.

Game: Nexuiz 2.3
OpenGL 2.0 shaders on
Vertex Buffer Objects on
Show FPS on
ultimate quality
1024x768

2.6.23-git
0 48
1 48
2 48
3 48
4 40
5 38
6 33
7 28
8 22
9 22
10 18

2.6.22.1-ck
0 48
1 48
2 48
3 12
4 6
5 6
6 5
7 4
8 3
9 3
10 2

2.6.22.1-cfs-v19.1+ckbits [*]
0 48
1 48
2 48
3 46
4 45
5 43
6 36
7 32
8 25
9 24
10 24

[*] This kernel has the cfq-* and mm-* patches from -ck applied, and
the above-background-load function from pre-SD ck patchsets (or
2.6.23-git)

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Miguel Figueiredo]

Em Terça, 31 de Julho de 2007 14:16, Matthew Hawkins escreveu:
> On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> > * Kenneth Prugh <ken69267@gmail.com> wrote:
> > > CFS generally seemed a lot smoother as the load increased, while SD
> > > broke down to a highly unstable fps count that fluctuated massively
> > > around the third loop. Seems like I will stick to CFS for gaming now.
>
> My experience was quite similar.  I noticed after launching the second
> loop that the FPS stuck down to 15 for about 20 seconds, then climbed
> back up to 48.  After that it went rapidly downhill.  This is similar
> to other benchmarks I've done of SD versus CFS in the past.  At a
> "normal" load they're fairly similar but SD breaks down under
> pressure.
> The only other thing of interest is that the -ck kernel had the WM
> menus appear in about 3 seconds rather than 5-8 under the other two.
>
> Game: Nexuiz 2.3
> OpenGL 2.0 shaders on
> Vertex Buffer Objects on
> Show FPS on
> ultimate quality
> 1024x768
>
> 2.6.23-git
> 0 48
> 1 48
> 2 48
> 3 48
> 4 40
> 5 38
> 6 33
> 7 28
> 8 22
> 9 22
> 10 18
>
> 2.6.22.1-ck
> 0 48
> 1 48
> 2 48
> 3 12
> 4 6
> 5 6
> 6 5
> 7 4
> 8 3
> 9 3
> 10 2
>
> 2.6.22.1-cfs-v19.1+ckbits [*]
> 0 48
> 1 48
> 2 48
> 3 46
> 4 45
> 5 43
> 6 36
> 7 32
> 8 25
> 9 24
> 10 24
>
> [*] This kernel has the cfq-* and mm-* patches from -ck applied, and
> the above-background-load function from pre-SD ck patchsets (or
> 2.6.23-git)


CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 
2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS 
then you are comparing apples to apples.

Details on the SCHED_YIELD implementation on [2]. Please correct it if it's 
wrong.

1 - http://www.debianpt.org/~elmig/pool/kernel/20070731/sched_yield_hack.patch
2 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html

-- 

Com os melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Miguel Figueiredo <elmig@debianpt.org> wrote:

> CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) 
> as until 2.6.22 and -ck. [...]

as i pointed it out to you it does, the function's name changed:

 /*
  * sched_yield() support is very simple - we dequeue and enqueue
  */
 static void yield_task_fair(struct rq *rq, struct task_struct *p)
 {
         struct cfs_rq *cfs_rq = task_cfs_rq(p);
         u64 now = __rq_clock(rq);

         /*
          * Dequeue and enqueue the task to update its
          * position within the tree:
          */
         dequeue_entity(cfs_rq, &p->se, 0, now);
         enqueue_entity(cfs_rq, &p->se, 0, now);
 }

plus others have tried the SD NOP-yield hack-patch and while it slightly 
improved the SD numbers it did not change the "CFS is smoother" 
experience.

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 7/31/07, Miguel Figueiredo <elmig@debianpt.org> wrote:
> CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until
> 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS
> then you are comparing apples to apples.

Hi Miguel,

I tested with sched_yield_ctl set to 1

2.6.22.1-ck+sched_yield_hack
0   51
1   51
2   51
3   46
4   38
5   38
6   38
7   30
8   27
9   22
10   20

After getting the numbers on all setups with the 10 loops still
running I went for a run around the map (I used the "aggressor" map,
if anyone cares).  CFS was noticeably smoother (despite the small
framerate differences).  ie CFS was bordering on barely playable,
whereas the above test it wasn't really playable (felt like playing on
a lagged server).  Even plain -ck was better (going for a run, the FPS
jumped from ~2 to 15).  I've noticed messing with sched_yield tends to
cause strange defects in the past...

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Miguel Figueiredo]

Em Terça, 31 de Julho de 2007 16:57, Matthew Hawkins escreveu:
> On 7/31/07, Miguel Figueiredo <elmig@debianpt.org> wrote:
> > CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as
> > until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave
> > like CFS then you are comparing apples to apples.
>
> Hi Miguel,
>
> I tested with sched_yield_ctl set to 1
>
> 2.6.22.1-ck+sched_yield_hack
> 0   51
> 1   51
> 2   51
> 3   46
> 4   38
> 5   38
> 6   38
> 7   30
> 8   27
> 9   22
> 10   20
>
> After getting the numbers on all setups with the 10 loops still
> running I went for a run around the map (I used the "aggressor" map,
> if anyone cares).  CFS was noticeably smoother (despite the small
> framerate differences).  ie CFS was bordering on barely playable,
> whereas the above test it wasn't really playable (felt like playing on
> a lagged server).  Even plain -ck was better (going for a run, the FPS
> jumped from ~2 to 15).  I've noticed messing with sched_yield tends to
> cause strange defects in the past...

Have you tryied the 2 modes of the patch?

-- 

Com os melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 8/1/07, Miguel Figueiredo <elmig@debianpt.org> wrote:
> Have you tryied the 2 modes of the patch?

Here's my stats for sched_yield_ctl = 2

loops  fps
0       48
1       48
2       48
3       48
4       39
5       39
6       39
7       28
8       28
9       22
10     18

Once again it was very jerky come run-around-the-map time, though it
improved over time.
For me, still not as smooth as CFS was (especially the initial player
movement, which was the worst by far of any test so far)

I want to get some better numbers than plain fps though, the graph of
the numbers is more staircase-like in this test but what it doesn't
show is exactly what's going on.  I can assure you the framerates may
be similar but the gameplay isn't - and in this test 5fps difference
is meaningless since it jumps around a lot (especially during the
run-around) as you would expect with the different stuff needing to be
rendered.

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Matthew Hawkins <darthmdh@gmail.com> wrote:

> On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> > * Kenneth Prugh <ken69267@gmail.com> wrote:
> > > CFS generally seemed a lot smoother as the load increased, while 
> > > SD broke down to a highly unstable fps count that fluctuated 
> > > massively around the third loop. Seems like I will stick to CFS 
> > > for gaming now.
>
> My experience was quite similar.  I noticed after launching the second 
> loop that the FPS stuck down to 15 for about 20 seconds, then climbed 
> back up to 48.  After that it went rapidly downhill.  This is similar 
> to other benchmarks I've done of SD versus CFS in the past.  At a 
> "normal" load they're fairly similar but SD breaks down under 
> pressure.

ok, thanks for testing it!

> The only other thing of interest is that the -ck kernel had the WM 
> menus appear in about 3 seconds rather than 5-8 under the other two.

under what load is that - 10 loops? There's no disk or network IO going 
on during a WM menu appearance, correct?

This could be a time-slicing difference perhaps - if you have 
CONFIG_HZ=100 could you change it to 1000 (or if you have it at 1000, 
could you change it to 100) - does it show any sensitivity to that?

the other difference could be SCHED_FEAT_START_DEBIT, does that WM menu 
latency go down if you clear it from sched_features, i.e. to subtract 16 
from sched_features:

  echo 15 > /proc/sys/kernel/sched_features

to restore the default, do:

  echo 31 > /proc/sys/kernel/sched_features

(if you have CONFIG_SCHED_DEBUG=y). You might also want to try changing 
/proc/sys/kernel/sched_granularity_ns. Boundary conditions: make sure 
that if you change the sched_granularity value you also set 
/proc/sys/kernel/sched_runtime_limit_ns to 2*sched_granularity and set 
/proc/sys/kernel/sched_wakeup_granularity_ns to sched_granularity/2. 

Other interesting bits to experiment with in sched_features would be 
SCHED_FEAT_FAIR_SLEEPERS (mask '1' in the bitmask) and 
SCHED_FEAT_SKIP_INITIAL (mask '32' in the bitmask).

	Ingo

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Matthew Hawkins]

On 8/1/07, Ingo Molnar <mingo@elte.hu> wrote:
> > The only other thing of interest is that the -ck kernel had the WM
> > menus appear in about 3 seconds rather than 5-8 under the other two.
>
> under what load is that - 10 loops? There's no disk or network IO going
> on during a WM menu appearance, correct?

Incorrect.  This is before doing any tests whatsoever, just using the
menu to get to the launcher for nexuiz.  E-17 wants to load up pretty
little icons next to every menu item, and "games" is fourth down the
list of menus... the three above it contain practically everything
else installed on the system (since it includes Applications).
Thanks, debian menu! ;)

So obviously on first load these things aren't cached yet (in E's own
cache), so its madly searching the disk for pretty little icons.
After caching, the games menu pops up in 2 seconds.

For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds
for initial load, same as CFS normally does for me.  I think the 8
second one was because I got in quick and the system was still running
some startup crap (so I blame disk i/o not the scheduler).  I'll keep
an eye on it just in case, but hardly consider it a regression at this
stage.

Thanks for the other experimentation hints, its always nice to have
that little extra bit of documentation!

-- 
Matt

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Matthew Hawkins <darthmdh@gmail.com> wrote:

> For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds 
> for initial load, same as CFS normally does for me.  I think the 8 
> second one was because I got in quick and the system was still running 
> some startup crap (so I blame disk i/o not the scheduler).  I'll keep 
> an eye on it just in case, but hardly consider it a regression at this 
> stage.

okay. If you suspect some regression then there are various ways to get 
less subjective metrics of delays.

Firstly, you might want to look into desktop-action recorders to measure 
precise latencies of on-desktop sequences that are important to you.

To get a 'cache cold' system you can do:

 echo 1 > /proc/sys/vm/drop_caches

this zaps all the VM/vfs caches in the system, so you can do an 
arbitrary number of cache-cold and cache-hot measurements as well.

Another source of information about desktop latencies is in the 
/proc/<PID>/sched files if CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS is 
enabled. For example here's the delays of all my firefox threads:

$ grep max /proc/`pidof firefox-bin`/task/*/sched | sort -t: -k 3 -n | tail -10
/proc/3016/task/3041/sched:se.exec_max              :               15865
/proc/3016/task/3031/sched:se.exec_max              :               31604
/proc/3016/task/3032/sched:se.exec_max              :               46892
/proc/3016/task/3032/sched:se.wait_max              :              511850
/proc/3016/task/3016/sched:se.exec_max              :             1013570
/proc/3016/task/3016/sched:se.block_max             :            14870850
/proc/3016/task/3016/sched:se.wait_max              :            32558799
/proc/3016/task/3016/sched:se.sleep_max             :            87667199
/proc/3016/task/3032/sched:se.sleep_max             :           430423009
/proc/3016/task/3031/sched:se.sleep_max             :          1206545563

'sleep_max' values mean voluntary (interruptible) sleeps - those are 
usually harmless and dont cause human-visible latencies. The 'dangerous' 
ones are the block_max (maximum uninterruptible sleep - such as disk IO, 
lock contention or swap activities) and wait_max (maximum time a task 
got on the CPU) values.

In the above list the largest wait_max was 32.5 msecs (all CFS units are 
in nanosecs), the largest block_max was 14.8 msecs - both are pretty OK.

(you can clear the stats and start the measurement anew by echo-ing 0 to 
the /proc 'sched' files - without having to exit the app.)

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kasper Sandberg]

On Sun, 2007-07-29 at 19:06 +0200, Ingo Molnar wrote:
> * Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > Im still not so keen about this, Ingo never did get CFS to match SD in 
> > smoothness for 3d applications, where my test subjects are quake(s), 
> > world of warcraft via wine, unreal tournament 2004. [...]
> 
> here's an update: checking whether Wine could be a factor in your 
> problem i just tested latest CFS against latest SD with a 3D game 
> running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the
> most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). 
> Here are the results in a pretty graph:
> 
>    http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg
> 
> or, in text:
> 
>          2.6.22-ck1                         2.6.22-cfs-v19
>    ------------------------            ------------------------
>    quake + 0 loops | 41 fps            quake + 0 loops | 41 fps
>    quake + 1 loop  |  3 fps            quake + 1 loop  | 41 fps
>    quake + 2 loops |  2 fps            quake + 2 loops | 32 fps
>    quake + 3 loops |  1 fps            quake + 3 loops | 24 fps
>    quake + 4 loops |  0 fps            quake + 4 loops | 20 fps
>    quake + 5 loops |  0 fps            quake + 5 loops | 16 fps
> 
> Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively 
> during any kind of load. The game is completely unusable with 1 CPU loop 
> running already!

I run quake3 natively, ut2k4 natively, and world of warcraft under wine.

> 
> Quake3-under-Wine behavior under CFS: framerate goes down gently with 
> load, gameplay remains smooth. Framerate is still pretty acceptable and 
> the game is playable even with a 500% CPU overload. The graph looks good 
> and the framerate reduction goes roughly along the expected 1/n 
> 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps 
> its fully 41 fps even with 1 competing loop running on the CPU due to 
> "sleeper fairness".]
> 
> [ i've re-tested this using other SD and ck versions and other CFS 
>   versions such as v2.6.23-rc1 and the results are the same. To get the 
>   fps result i started a simple game scene: Single Player /
>   Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not 
>   move the player at all, just looked at the framerate that is 
>   displayed. (i also tried other scenes and other gameplay sections and 
>   they all behave consistently with the above results.) The system was
>   otherwise completely idle. While i trust these numbers take them with 
>   a grain of salt, i'm obviously not neutral in this thing :-) ]
> 
> so Kasper, i'll definitely need your help in tracking down your 3D 
> smoothness problem under CFS. I have the feeling that it could be some 
> odd factor that only hits your system, and once we've tracked that down 
> there will be a simple solution that does not affect the totality of the 
> scheduler. So far only you have reported any 3D game smoothness problem 
> against recent CFS versions. (all 3D feedback has been positive, and 
> that includes a number of gamers as well. Most of the 3D smoothness 
> problems were fixed in CFS v13..v15 and it has not been reported to have 
> regressed since then.)

I believe the responsibility for my situation is both IO and cpu load. i
dont know why SD does this. my test is to make spamasassin process mails
while i have these applications running(and wine is most sensitive, the
difference is almost negligable in the native applications, but very
much noticable with wine+wow)

could perhaps be filesystem related, i have my maildir(extremely large)
on reiserfs, and /home on xfs. what my mail client will do is download
mail, spamasassin it(loading database from home), then it will put to
imap server placing it on reiserfs, and then a "local" copy in my home.

while i only see the spamasassin thread as hogging cpu, i suspect IO is
also to blame.

> 
> 	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Peter Zijlstra]

On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote:

> could perhaps be filesystem related, i have my maildir(extremely large)
> on reiserfs, and /home on xfs. what my mail client will do is download
> mail, spamasassin it(loading database from home), then it will put to
> imap server placing it on reiserfs, and then a "local" copy in my home.

Ooh, do you perchance have PREEMPT_BKL=y? 

If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL,
but that is obviously the lesser of the two choices).

Ingo traced a 1+ second latency at my end to BKL priority inversion
between tty and reiserfs.

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote:
> 
> > could perhaps be filesystem related, i have my maildir(extremely 
> > large) on reiserfs, and /home on xfs. what my mail client will do is 
> > download mail, spamasassin it(loading database from home), then it 
> > will put to imap server placing it on reiserfs, and then a "local" 
> > copy in my home.
> 
> Ooh, do you perchance have PREEMPT_BKL=y?
> 
> If so, try on another filesystem than reiserfs (or disable 
> PREEMPT_BKL, but that is obviously the lesser of the two choices).
> 
> Ingo traced a 1+ second latency at my end to BKL priority inversion 
> between tty and reiserfs.

ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 
code runs under the BKL, and the only other major kernel infrastructure 
that has BKL dependencies is the TTY code. Kasper, as a debugging 
matter, could you try to move that spamassassin workload off into a 
non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a 
noticeable difference (for the better ;) then we can continue figuring 
out what's happening exactly.

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Alan Cox]

> code runs under the BKL, and the only other major kernel infrastructure 
> that has BKL dependencies is the TTY code. Kasper, as a debugging 

And half the ioctls some of which trigger long code sections.

For the tty layer I'm waiting for the revoke code to get finished up and
move from -mm into Linus tree. At that point the real evil lock_kernel
related stuff in the tty layer can switch to using the revoke code for
hangup paths and then other bits can be tackled.

Alan

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > code runs under the BKL, and the only other major kernel 
> > infrastructure that has BKL dependencies is the TTY code. Kasper, as 
> > a debugging
> 
> And half the ioctls some of which trigger long code sections.

the tty layer has relatively short BKL latencies, but reiser3 has long 
ones, so those got transposed over to the tty layer, making it all quite 
noticeable to the user.

BKL contention is not a big issue on the desktop _unless_ there's at 
least one workload that creates really long BKL latencies. That 
multiplexes it out to all the other BKL-using subsystems too.

the DRI/DRM BKL use was a problem some time ago, but i think it's now 
using unlocked_ioctl(), correct? All the other ioctls are rare enough to 
not really matter.

with PREEMPT_BKL there's also some sort of random effect of priority 
inversion that makes the actual latencies depend on the scheduler - but 
we dont understand that effect exactly, yet. (hopefully Kasper can help 
us out with that. Peter got rid of his reiser3 partition the moment the 
latencies were traced back to it.)

> For the tty layer I'm waiting for the revoke code to get finished up 
> and move from -mm into Linus tree. At that point the real evil 
> lock_kernel related stuff in the tty layer can switch to using the 
> revoke code for hangup paths and then other bits can be tackled.

oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of 
the very few pieces of kernel code that scares the hell out of me :-)

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Avi Kivity]

Ingo Molnar wrote:
>
>> For the tty layer I'm waiting for the revoke code to get finished up 
>> and move from -mm into Linus tree. At that point the real evil 
>> lock_kernel related stuff in the tty layer can switch to using the 
>> revoke code for hangup paths and then other bits can be tackled.
>>     
>
> oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of 
> the very few pieces of kernel code that scares the hell out of me :-)
>
>   

Maybe it should be kept crufty then.  Every kernel developer should have 
at least one part of the kernel he's afraid to go into ;-)


-- 
error compiling committee.c: too many arguments to function

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Alan Cox]

> > oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of 
> > the very few pieces of kernel code that scares the hell out of me :-)

I'm not too fond of the way it does some stuff either especially the open
v close v hangup paths but that is partly the fault of POSIX 8)

> Maybe it should be kept crufty then.  Every kernel developer should have 
> at least one part of the kernel he's afraid to go into ;-)

floppy.c is sufficient

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kasper Sandberg]

On Tue, 2007-07-31 at 10:57 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote:
> > 
> > > could perhaps be filesystem related, i have my maildir(extremely 
> > > large) on reiserfs, and /home on xfs. what my mail client will do is 
> > > download mail, spamasassin it(loading database from home), then it 
> > > will put to imap server placing it on reiserfs, and then a "local" 
> > > copy in my home.
> > 
> > Ooh, do you perchance have PREEMPT_BKL=y?
> > 

sorry late response.

nope, i run totally without preemption, i did however test with, it
seemed to not matter in terms of smoothness, but reduced the throughput
slightly.

> > If so, try on another filesystem than reiserfs (or disable 
> > PREEMPT_BKL, but that is obviously the lesser of the two choices).
> > 
> > Ingo traced a 1+ second latency at my end to BKL priority inversion 
> > between tty and reiserfs.
> 
> ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 
> code runs under the BKL, and the only other major kernel infrastructure 
> that has BKL dependencies is the TTY code. Kasper, as a debugging 
> matter, could you try to move that spamassassin workload off into a 
> non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a 
> noticeable difference (for the better ;) then we can continue figuring 
> out what's happening exactly.

the pricess is as this:
mail client fetches mail
mail client invokes spamasassin
 if spam -> spam
 else filtering
if it matches certain filters, it gets put into my imap server, which is
reiserfs.


> 	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Kasper Sandberg <lkml@metanurb.dk> wrote:

> > ah, indeed, that makes quite a bit of sense. Almost all of the 
> > Reiser3 code runs under the BKL, and the only other major kernel 
> > infrastructure that has BKL dependencies is the TTY code. Kasper, as 
> > a debugging matter, could you try to move that spamassassin workload 
> > off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If 
> > that makes a noticeable difference (for the better ;) then we can 
> > continue figuring out what's happening exactly.
> 
> the pricess is as this:
> mail client fetches mail
> mail client invokes spamasassin
>  if spam -> spam
>  else filtering
> if it matches certain filters, it gets put into my imap server, which is
> reiserfs.

do you have any filesystem that is not reiserfs? If yes, could you, as a 
test, check whether file activities on _that_ file system still cause 
these lags, or is the lag purely connected to the reiser3 filesystem?

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

Kasper,

could you please try the "chew-max" latency-printing utility:

   http://people.redhat.com/mingo/cfs-scheduler/tools/chew-max.c

if you start it on an idle system it prints a single line:

  $ ./chew-max
  pid 14506, prio   0, interval of 99984800 nsec

and prints nothing else. It continues looping and looping (using up 100% 
of CPU time), and the moment it's preempted, it prints a line about that 
preemption latency. Under higher load it will print something like this:

  out for   63 ms [max:   66], ran for    5 ms, load   7
  out for   85 ms [max:   85], ran for    4 ms, load   5
  out for    7 ms [max:   85], ran for    0 ms, load   0
  out for  105 ms [max:  105], ran for    3 ms, load   3
  out for  174 ms [max:  174], ran for    6 ms, load   3
  out for  219 ms [max:  219], ran for    3 ms, load   1
  out for   78 ms [max:  219], ran for    3 ms, load   3

so that we get a picture of your latencies, could you run this tool why 
you are seeing those 'bad' desktop latencies? (Since your CPU has two 
cores it might make sense to run two instances of chew-max.)

record the latencies like this:

  ./chew-max > chew1.out &
  ./chew-max > chew2.out &

and send us the chew1.out and chew2.out files (bzip2 -9 compressed). 
Thanks!

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Kasper Sandberg]

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

First off, sorry for the late response.

On Thu, 2007-08-02 at 17:42 +0200, Ingo Molnar wrote: 
> Kasper,
> 
> could you please try the "chew-max" latency-printing utility:
> 
>    http://people.redhat.com/mingo/cfs-scheduler/tools/chew-max.c
> 
> if you start it on an idle system it prints a single line:
> 
>   $ ./chew-max
>   pid 14506, prio   0, interval of 99984800 nsec
> 
> and prints nothing else. It continues looping and looping (using up 100% 
> of CPU time), and the moment it's preempted, it prints a line about that 
> preemption latency. Under higher load it will print something like this:
> 
>   out for   63 ms [max:   66], ran for    5 ms, load   7
>   out for   85 ms [max:   85], ran for    4 ms, load   5
>   out for    7 ms [max:   85], ran for    0 ms, load   0
>   out for  105 ms [max:  105], ran for    3 ms, load   3
>   out for  174 ms [max:  174], ran for    6 ms, load   3
>   out for  219 ms [max:  219], ran for    3 ms, load   1
>   out for   78 ms [max:  219], ran for    3 ms, load   3
> 
> so that we get a picture of your latencies, could you run this tool why 
> you are seeing those 'bad' desktop latencies? (Since your CPU has two 
bad is not the exact word, its pretty good, certainly better than old
vanilla scheduler, just not as smooth as could be. 
> cores it might make sense to run two instances of chew-max.)

its a singlecore socket 754 firstgen amd64 :)

> 
> record the latencies like this:
> 
>   ./chew-max > chew1.out &
>   ./chew-max > chew2.out &
> 
> and send us the chew1.out and chew2.out files (bzip2 -9 compressed). 
> Thanks!

i've attached it(bzip2'ed)

i've come to think it is IO related, but not entirely related to
reiserfs, perhaps xfs.

i will conduct some tests as soon as possible.

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

[-- Attachment #2: chewout.log --]
[-- Type: text/x-log, Size: 12327 bytes --]

BZh91AY&SY\š,†\x05ô·[€@\x10@\x04\x7fð\0
¯§ß@`N\x1f>¥8è€BTöh\x15m(E­[*•-ŽŽµ5j‰h4ÕM1R"Š†Ú¯ŠQÓB&‚T\rU­Ù]ƒ@*Š\0\0\x02ŠPT®6Ø\02
\0\0\0\0\0\x01E@\x06§À\x01÷Œ\x11l\0\0\0\x01è\0\x01JH\x14W¶‚(¡UZ\0\x06„B@\0\0\x03Þ„5e¶FX"\x01CCT\x02\x06\x03L •PÐd\x01\x01§¡!* 4hõ\0\0%<€(UCA\x06@\x04ž©$€Rd\0\x03@\x02jJª~…^[S \r\x06†5\x02’Q$DÐ\0\x01 p(‰~r€Uü2\0ž\x11R£ó"¢~Ø€Fˆ'û‰Jž‚W!T舗RNˆ®\a%S©\x12ä‰tŽš:\x05Å8€ºG\x0e\x05t\¹Ju]N(ç*üüTŒóª®rUPá\x1cà@¹)^ Q-„ª‹øÒ§õè	Iz¡P\x1fð%%Ÿ\x1f\x0fÈKò\bÒ\x7f›T­â\f€\x17àQ\x1f™Ã\x7f…›fÖ„­2[\x02€\x0f€\x10vþ'N\x14ÎŒSp]\x13ÖŸbë}÷1A…2\x18*i€Ô	Ę\rTŠa{\x18bÞµ\x18ÙŠXÂÉ™™·¯µáÖÌqÁ\x06šs‰­\x18ÛÆö‰Ü¢Ûb\x05ßÃÎhóÇ\x05\x06‘bôèŽB;íœ\x16ošq¶Y'TI”§ÅŽíä@Ž:òù\bDömÞ$Ï\x02»f\v¢¬º¢¢tO•ú\x0f	3àè×ÇkûãÊ\x02ê\x13!~hèÒäú|e¯Ã0æÍ.\b@'G\x0fDëv6'^ZŒC>Ã\x1f„@Ñ{`–lú\f\x12UÁ\x03\b°l«U\x01\r7n9^[†œºì\x17w—Œóµg\x18˜Ë\x16Äk(äËìâûŽr¡c” Å«Ï·\v\x05õ>&T\r£­pK€c¯44Ô$T#Q	|$âlË"ƒj'#}ŒÎxäé Ý\bŸnËZ_\x19cAŸ\x1d\x173­hˆè¹%ª\x18©\a\x1a\x10\x12Ÿ‰h©ñÄpÁžÚ‚æ™\x19ˆb°é¥fí2aK‹f°ªHiï(}å‡h‚y\x05G,§äõ#\x06\x10!¬\ð›Ii™8äDúæ”ÀÊ%Ó86œoF\x17\«"?:S\x1fš\fñk¬86kPŒ^[ŠÉŠ¹Û\b„ƒÏemzXNònÓŸ\x0e\x1ag\x05Ã\x14­hwgŽ\x01ÑQÙ0]»Ù©M\x06°BU\x0e<Cò\x1f»y^žC[j?Pžþöß’Ã\b\x11 ñùÔwæ,º$ÕšdV\f²äçì˜#ÍRW–QܺÛVAB\x14â\x12\x18Á¢|ku¯\x1d×eâ’â^žÁktPèò<¢k^1ê¥\x17\d\x16Êé\x1fŽÇ\x1e|=qØŠ•‘ž¬È…ä\x05ëÙEr@Ú„Ó\Ã5"C\x0eKud-›\x17[Ê2ÝbH€¥#\x11žPõ‡„Û\x0eÁ
hAnYfíç¬+ÞUîW‡9+°	\b¯!Í\x0fxl=døÆŸ­œY|:p6xá^[\x02$§~Œ=ä8YCq>ì¹aœ<®ìYãI-"m0L\x11ã Ÿo\x10›NyÏŸ>rth%×/Œ6±\x11hc…dIH·o.jw\x1c|²#»vï\x04Åž1|/\x1d1e3}\vò,5ŒŸóÉÎÁš&ǐž"û2DU\x1a
֐ša/4A.n¶\x025/YÛ³Ö…\x1a\x13/Q;TBøáîµã³ƒÛ\x0e‰C±±h¡D·Í‹†Qh-³DŽÆm\x7f!Ÿ=\x1cÉŸ†±#\x02\f\x15Õ\x13=áðû¯íÍ;1úÝ‰&{§ÍëœôKØœ9éF_¯Æ\\x10FèÒ\x01#ç
ŽÆŠŠ—·mðŒS­šÚëZ…ºš\x10ÚðçŽ	_9눢³y>¹š"©ËÔŸ9ïÛŸI5Ó‚] ç"TKîlTÎ!\x04\x131ÇÃãKõÅP•>t¥ëÀZ,àƒ\x18±£\x16£$i0,i}É\x16Ÿ8ƒÆAP¯>˜ðù÷ZK…\x14\x16nÙDº?žŸIUúÀÝkHy×Y\x17k·\x1d5Z&í5\aݝ°»\aÊ4sS™ÇUÉÏœâ›$(ߺ~æu2ýy\x0eþ/\ÜvÁHdQdPð€\x7f\x18П\x1daÙŽ\v§c_]‹Ã<%\ba €m\x12\x04Ô\x04hò!f¹ùãC\bÍë”0lÀY\x06ä\0Lb€éÃ*¿re­$þƒSÃ\x0f\%êØ\x1dJ°œ\x17ŒŠ¶ëföLñÁd\x16sŽŠš@‰âÓ+u'9$yÔ8êfŒ²Î8yœÍC”]Ae°N\x0fk\x1a{‘\x06©ˆ:ØDH·R²—VÄŸœ\x19LZ*hšï&”ÈyѝZÙ¢€Ž\x1d)\x05è¶$ÅNm'µÔÇ€ŽL²’\x05c§^[Ûâû’à”CÑ\0Aec÷•†Žo×\x15ëà²\x18Ä4òœ­saÒ赌ôÆ0Œ‘€…ãGÄYŽ^]\v;$\x068\x12ñøjñ‡·dtW»$™##Ê&aNý)£À\0\"×Qp¬C\f\x7fN«›×Ž1‚m\X•\x10DHÚT—·7.šHëT»˜‡^[ø­ùž`ªkÌâú€\x1a!\x18ƒuqÙáØ‚ÂAŽhø€‰>Å9\x01Ï1ÀÉ \x1d"ö\x06Ð\x18xžYçÝc\x12„&qœCˆM\x04MùŽ\0”\x17\x0erG}µA6>‹\x18¡ƒ\x03’G\x02=I_\x1dÁìLܵÉÉ×6 ÞÙ©#˜lB	Œ\x16©\x15Øä«bŽÁµ™	\a×5\x19œãÑ8ÄgE\f¢é~ãÛÅS^…'\x16Ç{¹tHÝ뀓ï<H\r\x06¬Æ”ó\x16ä.ó#BύB:Ã÷=09F‹hzK\x1ewš(ù\x04!}Z–2Ý=ðÓ\x12Ó>;]\x14Nž0éº ÐÝÝÛë88®|KœÐ„\x12C\rSîKZ\x7f8%ELȈ%\f‰\fk­­,ix‚Š3\x15\“84S\x1dòÓy\x1eíÇ>9*¹›Îù8u\x05&¢dìQ&aHEŠP2•$zêîÍXJg>Á’C_&j¥X\x0fbí™P¡ÇŽ»ÁS\x18®¹éLÖ\x1aÓMyŸ\x1eñŽHY\x14Ä5 |\U*k²âCÙ\x04\x11bé$uYÍù…TǯJ|.Š\x19À\x16Ç\f¢@\x020@r<!䏹ø¢;Fì\0ÁªÆ\x1eö‡aq\x01ÅBˆîǬ8Rë–zªxX‚€\x1dgÞ\x7fWžž%\x18N%\aÇ÷ÈôÞ؇;{Ü-±®\x18¡œo\fFyŽš™/Z±æ‹îºssãw„éJ\x12Ò©b`¹˜¡ÚÎL»~ºµŽ+yr +i‰‰›nEXÄÆ ÒJÀi\x02Ó\x18€‰ÙfKb_G®Ëç\b^i\x16ˆ/!\x19€ \0\x06íš"\x13MÏ‘ÏÖ{ìò5\x06ŸK\x18žNMBQ}msðåÛóÑRsvâ­vُé1C»»Î5õk‚Æ&`R\0ŽåˆéyQ+\x10\x03ÍVDϵ0|@ñ\x124\x13¢CºÖˆ×÷\x1a>u	£>–#Í\x1dhFŽ<O~çÇ8•\x12æ‹eˆlÍQ\rÄ\x15Ã\x035µ[]’#¯ Ol\134hð—…\x04ŒlhgL÷ž>UO\x14B
ÐÚLFŽ –tÎ\vEÍa~çy¹Ñtc1‹ƒ>:%\x16Ùù]Û2~²fŒ%\x16\aP\x17ÎSEC­>qÇÆHLW¶hÚO\\x14\x11ðÑ\x1að¡­ætÉ\x1c8e­œã€M•‚^[\x04^[2(Q\fŠÓ\x16y7Ð\x19ÞRa\x1e\x06ÒÏ4Ä	EKµm^[E1á[f|'­bøû%l[­è\x18 …Ë33¯˜š@D0lŒ]|µ›ÆÔ–†\x02ÍÁ\aÑ‚éÓkAÒašQ«Ž}æ\x18±xŒÊ²ßzð‹Ž7PÇ*\x1a„\x05j\x12tn\x0f\x13=—éÄ+Û»$"\x01žu¯Ÿ{OŒõÞ]J…Å’j›«\x1eA‚i\x0e×%\x04Ré\x14Xx\x10Ž\x11eÈ÷%ݏZŠ|hvF^。VKä²ÙCž·C\x1a³Š]±.\x1a\x1cp#ÅŒ”ž\x1c\x16{ŒQªŽ›Ÿš ÏŠ\x01\x1f[RµEߎ(O‡×³\x15&Ø‘9Ú „e\x1cj\x19¯±šŸ_yf­×‘ ¢¬Y#ñC9YëC$0\x18H¡ÀÓ(œÒ-MîkbØM°^[²\x11a£PèÕݝqÄ€Ž‰o“f+ŠV–å¡Ð\x0e,åãñâˆÃ—\x13ÜB\x10/—\x10R³\x02C¶v%a\x1f\x17\x13ózåøèžÀÜ\0\x12\x0fuš|&Ž³ƒ×Óuv/Dï›Öʆ8ñh	\x16[›öڐ-j|îëœlI“îtU‹FäZU^[ƒ„"Hé¯×q{Ú\x1d€\x02Úöß›ƒK{Ð"=8HM"<@2nË•¹tWnБ›ô¯^[µM,ræEyÊîå‚F¡‘²\x14YŠ\x1c Rð¯‹e4ůrÙ\x1a„wë7b@º/EÇÏÛ9KY-»Ëµ‰á@lF\x05€ö-5Ù`Fü%Šà^ŠFží`«o>jF	\fM%Ä-µE\x0e\x16ìì\™5 Ehm‰‹›q:ƒ°ŒN í“?¥!×8„i+PCVA($N˯3u A‰Šó\0m\x06A3
0NÑÙöè”l13LñœÜ×3Å€Ûb1™ŒM0ì\x7fy]U \x172\bïœP)=)ÖÃå{j\x14j\x10‚ç”>ÄwÏ )\f\bg]™m\x11g]\ŽÖ\x16‚6oæ\x14ç\x18ßEª,N\x15dÇëÎRˆ\x18š—oM Ž8Ž\b\x15\x05×%íšÈâ/·TWï9¡®{¶u\x05"‚HHä¢ÌéÓ\x137^ Æ€TJ\x18ƒ\x102\x03›¶\x12k×51MdyOG\x0e!Æ}Ùo/Ëy¯\v/7Œây×öùå»1Ãõmwí¯\x1ašœ>¡×\x058ŽÀ\x12O;\x01\x15Ç\’~€ë NyŒÞ –µ‹Š{_OŽ\x02vồZU0LC|qGŽú«R¢‹„•ŽÄ\x18¢3\x03 —c^!C*<‹ŸÏ».*œsÎsÞÐï3b\x05÷Ï(OLš×ké+›"8ûXaZZfŠŠŸ\x19'g\fJŒM\x1e^[{$Åêòljlt`3U\x1a^©íç×\x03|þ\x17D¹æq®ùï°rÑ¥Ä4Ì8Å\r2ÔZë\r"Éã4ÐÙ\x1fM@e£Ó-GĉŽÓ³ÝV\r{•\x05uNž\x19­ã£@„%¯d\x14\x03[\x05^[\x11ìN7í9·\xÙÎìIHywXGžÞ9gů&²4\x18ÌGZ†–4uX^m1
¶b¯³+N\x16¿…oÃót\x17 וß]*Mæ\x02†%Ã!‹LÑ,TéÎiµC#ïÖ\vƒObˆÑ‰\bèÄ‚‰3\x19°RZÅEg2?\sSë8/\%TωPuÎ §\x13'\x05‘z˜w’óÑ«•™ùÃV úùÎ7›\x03Ü—Ê×õ‹›«,‹µš\x0eEQ+ÇT˜\x10`fh¶®ÞH€Å[ÉTZe-y\fŸäYðÜ<&–‚\x17j\v\ñ\bä ¯G$ó\bŠÃ–¯­­’wj–L\f@«jŸD±”Äε5Ü]o<%`ó‚ž©Ì\fcæÊ-m d\x10bŸ{LJœ1\x06:Ó\x17\f¢ÖB @»ZÎ\x19—^tÍ\x12\fÀ@˜Ÿ&ŽƒHÖÄŸ\x16ü†\vLK•öÕ4ÏqÑ!\bùã^ä4@0äAž5Š±ª\0Úq\f"¬…ˆ\f5ÍìX„JËŽ,¥Ù×v…\x18B\x03°ææŒ\x01ÂO\rA¥í‘yž.ù€\x18žo[dÒç\x0f‰7Qlo
*Æ—\x1a­#¢\x15–ƒ¬SP„T["[ç7Ï—Ä>ÙÍ\x1cÑÇ\x01˜ ÌH\x11²xÑa×yb‚‚\fm ÀmàuŒƒ\x15m"<\x04¹\x14"âßDyӐ\x1e˜
!AC!‰@\x18bšò\v\0ÞHR\b\³\x18˜NZ!/o	Ÿ\x19¢\0Ä(Ò\x05‡Ï\x19ÚÔ\x11}Ê”«Ó9Á*Å\x0er=k\x04*cU°G{¡ªjÁŠ\x1aæ[.\rfCŸP…ùÃ\x10*`e\x15#tˆU€Èמè²\x19U\rJŒÔÑÇc$<æ\x1es\ã÷õŸybë|0)l®¬kÒ\x1aê\x11^[\x12\x05ÑR"⋙đúüw\x14âUþK—\x04ZÓY!/w^\x14s\x02<ª\x11†ÈXuØ;\x10\x1eƒ™¥ò\rpSÎJ®\vÎ6V»»^[°Ì"h5µ}g»ÙÓ;\x18Ac¢k\x04\x02‘šŸ^hçæïvïœÞ§w\x10\rdÔ‘¥	ÁFŸ³¯¶êO6$5Å\vås†œˆ÷wžîç0q¬œ\x16Èû¶+›™ÝWIÝB]&äÉ\x05Tù\x15CYø®qy\x05ËD☶R¥¥Â\x0ffzÀ¶\x10)VXk\x18\x148Тh¶É¬kMˆJ\x16I\x16LD`LÓ$\0D\x14ÒÆ„Kùˆ£f\0\x04§ñn6د"5st¢åÍŠ*¹;®j¢	"Ä\x16ç*b\f!ÌRdYÌRE$˜ÄQ¹\¹Ì†.\ŠÉ®\̃HFL›rÜÑ¢¢Åp$‰šb$\x04€I‘»·WvåÊ‹™7+¡hØÔlRS(ā\x14V5ÊåhÒB\x04\æƒAI;¹ÎcRLœë\x05\x10iwš*g\rr€¹B9’X2C4\x1eá<! ¬•™UÝ»\r™ËŽ\x1cæ9'vé	D‹\bZŠÉbÉÉ#\x05ÌZÈD\x12&·/5|Õç5Í»»`ŠÝŽQŠ^[›Š(<¯ŸÞt\x195ðÃ$€1Cb€sŸŒéÜPèni£¥“\x06j\x02„aA1²	\x19`t\x17·mÒÀ÷báÍ;šÑ\x15ÊÓ
`\x14H\x11d\x121\x04R\bÑwrv/79ºþvŸ&fXÐ^jY„\a_7¶Œ&îµÂ5‚’„I¡ŠK\x18“ `õî·œîêžk–Ñp‹^[\x14Sº˜e)’9ÈY+$$;º\x05\x06JCD2Æ$áQÃ#uç»&cºì	(Õéo7j\axè-äŠæ»ºæ‚ˆ¢™$v/]Ë£s„&JáÉ"4È÷^_}個ÄÔÍ’Aw\x04œÇw&\vb$îÝ€ØÅ\x14h’#_vóœzUyŒ]×Q\x18‹daEÎrܧ]]1	$”b×:ŠHÎè·LN™vÝ\x1aԑÝÕ¹sPÊ"åA®Ë&ÇMtåvZ\x03\vºº)„±±%îœ\ÁDËÝÙ˜¶.[‡#›ºíËpS+Y"šÂ^[dˆ“`Ön䚈¡\b…4\x10\x1e‹bÑ«ÉI\x10Ý’œÝœìDD€’K.nPÒ»–í(˜ã\x10".\b¢ˆ…\x10€\x13Mcš\f³zêé²W-ré\WÍnû»TÌsnéÕÉ\x03%;®‡­J9€àŽ% ,âïx)5 •ù²·èûßeö/Þ÷·âºÜËÎ!\x12QŒ%\0']Î{£E\x01®œã\÷ï}}õ\x19v,‘š\b“›…;)\x13!Nåæ™b‹œ£€Ý{°N\8hœÁäÙºN•'\x13‡8êXâvåÍÐäFÝ\x1dœïG’÷Œ€Žs[ghÙĆÆ&£GW5\s]Í’IÉ\x19hª\x17\vsz\a\x1cΫƒ}·‘_Š4ý~öøî_¿{ÙæíÂÒ\x1e§u\x0e•\ÓdXVæ\x1c\x11s­š÷eq\x19 E ÛQ< 	Š¡\2É\x1cjWH`\x10b\x18á’ã\x18\x0enUT+Uã`ŒfpœV%&Àå‰k\x1f£À:\bv{÷~“ßáõíú®Ì\x174\x12b/©šîZéõÝ,ª¬\x16@œW–í®HŽ™	ciº™\x1fdˆ3\x16\x06 Aˆ(ŠÑ¢Ôh,\fÊ1¡#DÄ\x14bÄY(€\x10LR@C1`‰(\x1325~‹&,\x14Ö\x10 h/Ù.óy\x14dMÌmsr«œ¹F·5žX®[€•Ë^[pѹ;ÍFäQ±‹–¹\x11š¶#RQ\x18£ræ"É^[^[\x11r×Ks™*îì\a,•¹£i\x02‘#‘ÝÖ®[‘·6MÎ\x13»r®Zç$Ð…	NwguÈqÜ`9È£&¢(€\bpÅÅ\x02¬«\x05PRV\x1c’qAd&¥Å™Á\x10¬š\x1a\x10F\0Œ\0ØÐEs˜±±r‹†‚˺é\x14çNvîài€­ÎD˜Ø\x19ŠåËšáÕæJ-„Æ6ÅœwmtÈS5ÎûÑ\x15=¯–$”‚.:á\x0e"“9$8NC†VEAÎrä\a4c:è(étŒwuݹ§:L˜\fX‹šäwu\x16\0±·Ê·»¶Åªæ§w+«›\x1a.îã
C\x12c\x1aP
%Kûõñ?8»¹ÎåÔÒI_˜\fYî­Ê•IdÑUúbQ'ßO£[ã[í}õõõz}˜Š‹\x11"4M”$Å™4ð)%÷kÍ^[ËEbÇ4G Ü®XÛƒ\x11™˜\x12Á¥ÝÐåÇ8LUÍÀ4Šib»\òèŸôŸŸƒ
ey®š1sWÔ\x14F7·Ÿíò–ú\víÕ×Ýç„Z1€Œ£LY\x02M\x11\x051")1_)\x19{ï^ŠŸ\)5\x1a5Ëœ×\rÆÆ5s\å͍͢0”ŠF\x14!#F¢»¹»«‘b¹vc\x04\x06ŠLîæ\x193\x14‰\x11I¶3ë®Ýóíò€2»®2\±t\x18ƒ\x15¹[ì$\x12›ï¯4ÛyKëÞ¯1¢„C&'{Úïu\©s±]H(’ºk…%ÎlÒ]éÕûïDÛæŸI+œ=ܱ\x12JQ\0 Sº”1»ºÜªæŹ\x04lZLa Y11@S©w²j+òù§ÝÌ©Rûºl‰A^[Œ‹G7\x1dv\x0eîJe1G:è]3\x10Éb^[\x12)\x19\x13u\x168mÆ%\x10\x16Nî’%qÅE\x1c \x18ŠL\x06ry^j#QšÌ€\x12H¥îæ³L$™4—-Ù\x06\x02Ý+vQÍÊd\x15†ÆbæèFLœ®˜B¹]›—C207]]\x02Êî®\x1a#)™³ºº‰ŽíÉÝv\f)Ývç\x11\ã\x04˜ )\x016XLˆ„]m^ØL\x1eÜ2\x1eî\x03\x14c—mÝståÝÓ—LÑ\x04w3 hæéŽ6K$\x13;Ž€	Çvs)Ýœâ^îb1¡Vä[se|ÚW}ç'7+œ.RF7wnnjåË…^[\x11¯}ïž÷Y¶ŽeŒDcŽ+Š­X¡\bhï|¢zãvŸ\x1ab××ç}y}ŽõßK¯œ×„\x13]W\vÛºôá’\x17s.—qœ\a=(5ç%I×\x18¹DÂàÖ9#̇žïu±ýÉúyëÍ"€€Ýtɯ\fB›JƒˆŠHÔšÒ¢ŒÔ£ŠÕ\x19¢ƒƒ²Î)G\x13LâU‘18*o\vx2+¯zw{iVÂ*k\x16\x1755¹qsaÖÓ˜¥ŒJÃ!,Åš'\x18׍Yi\x13¢;–k€‰fŠšQ\x13LÁjM\x02»lêj»Nkh„S\rb\bàÎDä»^[¹\x15’€³\vd*^[™ÃÜæ..
(§lŒGº™Õp\x14×JÈŒµ–Ihyµ:œáÚ)s\x14è{œÇÞö\x0f¡\bçxpã*©ÃCb@Ù„Cœ¬Új2HœhS#°\x122R\x06R’š-\x19ö݃š3¶ã\x14'SE¶ÚÈwI@Ž‹\x11\x02Žš“\x16×XÒ‹jq\x052*Èï	ŒCâ↶X滵‘SBמ3·¹çÝö;¿\rÎøëðÿ_§ò\x05\x12|_è$>Å)ä¿'«Ôšœ\x0fgŸìTzŠ^úõøü©>)\x1eýoËØz'×.ŒÏ9ÙŸÎJr¥ËãÈ©à+Î\x03©\x18™/:tk6Ÿw¿]U=JŒŸ<¢¯\x05'¯\x14<”Ÿt]UŠ3g¿9SÁ<tG	bÄ{ˬS%xå\x17*\x1aV)–LÖ\f\x0eé\•¥€Ö¬VTçŸ\x15xCº\x1d\x061“%ç*ä;ŽLÖ&SΑÕL1faƒÎ'*Õ†5«\x179.‹M6eŠ––2Õ¥†\x1dË–ØËLkYªlÔ²”©•Î€³I	^[»u)h
dÉ)\rwtm\x16Å\x19\x13F\rÛÞ­[Ûm··Ÿû)^”ŒJÑ'Û•:\x17Ÿ^û/C,mab>¹\aQ;Ï\x14òFš®×ÌñV)ï)\x1e	yÊ9\fšY£VŽàêZµ6²²j˜\x195¬ÖÓ\f­$ÇóµÛ^Ý««LÄ¢Ò£	MšÊPŸvê)J™’Ø€Å÷vd›$•–Í©VÍ+ÇAÅ>prŸ]qf1‡Î¥ÐË\x0fN[6ÒË&\x16š_»Wmyyìûº¥›2”ªi‹\x18ˆþ»“\x13/7I•ý]mÚËM¢¿¥È¯uÚdI3d›&\x16*b,gõÕÔŠ\bˆ¥\0˜„Iüí\x7fS[·]µ©¥\x15Š›\x14_ã¢b|ÕÍ\x06(ÜŸ÷j(€Ú"Å^[\x16Ä’lc•æÞm\x15\x184›\x16¹«š"Üâ&ÆwW,hæè\x18G¿Ÿž’˜Œ}ÜÒ&Æ"
Û…œç\œëÃ2\vQQ& ‚ŽW\x0f9\x16ås\x05k›vk\x14r®ZbHŠƒ\x1a¢çfûÝoBÎ†ÅæÜ$…wUÉ0hÁ£l^G2\x18\x18˜Â$‘&
L&Ä\x11±Q°œîlî\x19'L/9êéQ’Œå­åŠ7wœ®Q±¢ƒrÛ–1%Š“\x15{ž+\x15IIŽmˆ×-ÜèÙ.\x1aá’Œ…EQ©1X£sNº£Ouïº×/•€*-r.\x18Ÿv¹Wšç›—»šBåÈ·7g—31·-}î5ÍW\x12"Á&óUÒùÄ÷G`ÊhƱEò·I1Œ\x11¶#\x16#KÎ建r666LšÜ­ÝÛ^[\x1675òÞTQ Òmˆ¬F$DxnÐe;®ÝÜ÷w¹72K·r \x051Ïí^†\x03\x11…ç\x1aPÑ1~m²B\Af$%\x12ï\x1dGpÎTª(¢€ÑŒá\x166\x04’"Å\x16÷qbžîŠ6
*6"®[š?·Í·Ï™)îŒÞmÎhŠbŽF9¹ åý/f"¯9&‹\x06‹c›EÓwur¹hЕ^[•\ªŒch€Ø\v1,\x06(š„®X®r·9Ê\x01”ržÍ®\ž[Šù\±æÛ‘h€ÔFÝÝ£W.Q“IˆÛºíˆÔm’Ź·wj¹¢ˆ£–º\x1a6’¹ªæˆœíHœ×–ÞcmüW-\x15\x1a£>í͍\x1a5¹nš6±¶Li-\x11\x04d¯•ï\Ó\x06˜Â\fŒŒ‘7÷ÕǝÎ$e\x04A"ÈbùÂH4.˜%%ÓšI1I”\a
€I-‘Y\x0eîN;,Ö¥\x12Y^š=5€£^[•Ð\x02\x1d×J)Ý\ Ñ#r×(ÄUpPJ'2W2ŸìÙÇb\x16‰±\x1aŒlHŽëŽèãë«ÏI\x03	®ë¶ µü÷W‘¥s'\x17yg\x10ä’Ô#‹ˆ„šilCFc@ŽCˆ¬–	Sˆ»JæÛ•ï.¹Î÷Ÿï²D@ X ó˜’Hš“E\x15Êå‚(¹]‰Ž\x13\vLÝ+”…^[»¢éq1Ã]˜Œm¹ž†-óW^]wu^[I¬£#\x7f‚óoM%F…9ŽB£C\f BËd“8uÍØzÞœnºíEºG8»ŒœC\x18×—e—\x0eÆŠ\x06îã2\x1eã]îî»\x1d7.jLm\x14\Ü£2‘4fm6/®uÍScGHšW(\x1dÄî\x13¡ÖoœÞ[·øuÈ%\x04ч¶ÚA,Ûb\x061\0`\x01†
5í S\x17\x14Ú!§%wut»Šƒp®\x13œUÎQŽSwHr±sœŒs\rL:䘡ԕÉ!\¬ƒyº‰œ„¡“\x05“•±4B(¢¢+ê\x1dfK›^[lnã’“‘1U˜T#‡SG\r˜œ¬že–Ĉ“’.DXŠHNf\x13…r‹\x06óÞè©\x13dQ™Ývo¿Ÿý÷h7îèÑ‹^józTV-Ë€Zç#$h›s¶e\x04–Í'MCSPÑ5	Á\x10:á©å$Z69]\fb!.Nè¢wk…\f"¹rB“Nî\x06¢%Ë\×wZ,¡Ó*T­\x10â”Krµ9ËÛÍîMYÓŠŒ›óncF®W&kÓ”A¢€ÜáÍ®Çw4ráˆ.UvlDn\ˆ×,i Û›\±ls®ìîE9uÊÎ\x14,Öº›Ž:Øå»kÅ=çœ[\x191ùrîì&ˆ)\x03EÉ„šªb÷Ç5œûçOŠŠž*ú… Üé\x16$	0îwwn1‰r²Ç\x03ÎŽ²"¶îæÌ°¥–\x1enmç"ëŽâ@\x1a÷rkúûŒH­6€Š*BÆ
#¢‘¥Â\b Å™\x16²;®k–Œr¹ºçl"Çwf#3Çmr#šáür±LÃøì^s\x11}Ýš
ݚѱR¹È„ÌnëŠ%ßÏ^XŒ·\v\x17wTbÝݱ\x137wh$(§us\x053s\x16âi6ƒk\x18×9ŒQˆ‹sr(‚±Dkó‘žî2ewvRIšîì;·ÝŸÊ+t€Ø؝ܳ0\x16HÆùnšæ‹WHÕ\x065\x18Â÷mÊ,D)«Ë^kÞírœÝBy¹F*‹\x1a(ÆÅ\x16Œš’Еr+†Š&¹»@â4H"L\vŽUB‹\bŒÞõåËû÷͈Áƒ#\x10\fFžêårs®^[œŸîMˆO.JKÝÂ’6\r湈w]ÝÃ\ÜÄ\x06³g8\x05®Uän¬\x13†KZô|÷:#c\x05"©ÔœÅ5'\x18dg$©T)`’pf0DJYB©ˆ]‹as$ÂnnjŒ'œÝ÷VŸl`Š\x19|ç7,_-ÊÄj0\x1a-\x1aB+Ïyûß7ÄÉo—5\x18ÔEîìm\x06M±lU×qtìîÆË–ì8áDB¥)N)’C‰Dšr€×	çc©Ç!î“ò7ÝÜ\x0e±Š>\Ä”\x1a\x10·^íŒ(yUÌ÷\±[Üžö¹²T†ÉŒ×6£cb\rY‘ w/œ¯#llw]FÆÆÑcʻË\x182y­Ò¯-ÍEÍÚçrºäïwÞß Æ1€±Ÿvøž\ÕÝÕ‹Í^kÜv1£A\x7f\x1d(£^p»—s•\x1aæØbî«€×Ýåœ\bŽÇu\ˆŠ4Zæá·wVA(ŽPUËy^÷»Û\x05išÁ\x05bÁ³4÷]‘5‹hš«»­'•\ç(Ô$\x01IdÞnE\x13×W1\x16ŒTmyiÝI·w\x06šÛŠá‚Š,l9Å¢ÆÛÍÚôìIQ\x18¹µÍE‹FÎ:×1‹æÜ-ÊïuÊŠˆ4\x1a2m˜çl„ƒrw[šÜ„µ\x1eVéb·–¹sæ·•Ë’lT”kssÞï6^ê]Ÿê¹XÑ\x1aœÝcF$ÐW»«Ë\µÍn—w\x14ÝÕtÅŒk›s\x19ݹµ\x15\x1cÛ—Î~n^[\x15\x14\x01Fß9h40Û—J‹œ§u·e\x14RZws\x11Xš-\x164\x18³Ÿï^QÜí\x11%üoO?¥¯Þž\x10ß9uŒª2\x064\x05™*-,¡\re¬¡Yª\x13eCe[Tl\vdCeTmU6š\fh%µI6
™’£d\fÒ–Å\x06ÅY‰[J•‘a,Щ°%²I¬…µ&ÀlU,Ò“b“d-¢V•¢VÈ­a6PØEŒ£jl£hÖRÚ^[VËŒ¿JKâ\x15ç£ËvÚ'kµWj9kF¶VÆŽV6£\x1a6m\x05Ù[\x1d„Ú&ÖĶš6"ÖÅV+h±mX²^[HÙ^[U6Ci²l\x15Ž\ae\x0eÌÍ«µ;Dl©\Ö£m\x15£V5^[j4\x10†Ò»\x15vM…µ6[[(f%°\x16ÊNÒ»T¶‘6–®sk\x18£FÑÍÊ-­ªµÊìÖÑbÆÑX­^[NßX<Лl¶\x13ÌUÚ\x16Ñ[*¶\x12ØSh\r lNÒ¯Ÿ/26€l-–Ð-ŠÉ%°”•±lS`7§\x15(]¢Düœz
€ŒôxÉŽ¶‘²-ŽÔœÐm\x16Ô+TkEXÖ¹µ®hŽZ(­¢‹\äh‹PVÅFØšµk–¿¥ZòÄUŒ£jå\x11k\x14•\x15spß×øö¶òÕŒXš­^[^[^[ó\Õù®Ëh»Pí±6¯q;[H|Ïq^`Ù"­‘Ž’Œ•T1H²U)0O4¯4Gu¹h­£QŽ\Ûnk\x1a¹¹ªŒ\x18Ú‹hÖصŠ¿‹W+\x161Qk\x15chŠÑU\x16ÞW6£\x15µŠ-±ŽZÅ­\x15\x16·*æ°kcm‹büܵ¢¯.Zæ«\x1d7ñnm\x16±h-_•®^[j*ŠÆÔ\x15j-lThÅXùkk–ØÕ¶›R¥&l\x05TOªµ-r5&£hÁ­\x16Ç›s\x1aÎk–ä\x1aÚ,ZŠ- ÛsUÌm;«\x1a¹·#lW\v\x15‹SùÖ®–µçñ\Þ[BlmA\x15å/\êxËÆSdvºU\x11T\Šì¶ÅhØ¢±m\x7fJæŽV£Ë\ڍbÑ\x1a£hŽ[F¢ÛcXÂXÚ-¢(­\x05yW5Œdªz>üžkccc|ëw.îl?wl^[\x06+\x12khÚ7œ­ä»*Ì>úŽÔlU_F¥\x05hùù[yŠ-\x16J’Ƶ\x16Ñ\x1e[k˜Û–®F¿-ÍF*ɪónFÛWÝÕ„£måªæƱ·-ËG5¹šÄky®m·ù6æ°b£D[ü—\rŠ‹~mËhþwmy¹¯ã²Œ·(ŽAŠ3»\x15Í`֍µ÷󷚊*ÅQò®j(7å»<gcm–ޟßñ)TOô‚¢\x7f⎄tšâåM\x06FYY3\x15¬•(žUH“õ\x15\x17Ó6¡%‰¢J±±K\fˆm\x15Y V²
Ì„Ø«jIµ jÖÉJlFÊ¡°UlTm­H¶ŠmQ±^[\bfJ­š¶Jµl€¶Q°Eò	I{|A)/(\x12’ú‚R_O¯ïòÿ<Ô\x04}*•Ij%+\x05e\x14E÷@”—·{œ¿Ø\x12’ö\x04€Œ\x01)/°\x12’Þ¶ð	I{UE%מ\x12’À”—Ûïø\x01)/ŸëU\x14–ùÀ”—¥TR^ÿœ
€ÿÌPVI”Ök_÷\x10Á\x16“\x16à\x10\x04\x10\x01\x1fü\0\x02šaçÐ\x18\x0eßBïTò5\aÕ\b&š­¶Ù-­›+[6‡\t^[Ec *V‚Ž¶!°À\0\0\x02€\x14P\x15Cè\x03 \0\aD€"
’+[F5–\x03׌ô¥\0\x02€(
\0(\x04ì\0h\x12J+C!Š U"¢…	P>õ\x1a\x19%\x06§„M*\0\f€\x04§¢(Š¡§¡\01\x04™IDJ€\x03 \x01'ªI*$˜˜\0\0MJšÒzLF!†§“@€”©\f&˜#\x04Ú\x15\x12û•"M\x10’šû©@zQ «\x12'4B쐚ꀎ•\x01qRŠr%ĉ8‘ÒS”’蜩Ԫèà¹QŠÔsÑšÍG4;Š‘'!âDIp¡).4•\x01ÿ¡)/\x1få™ú$qþ’8§á©øJ»­ˆoâo“3“\x0eeAtŸ+aë)õÜ®õ»Çœ}{\x19Tä\x17\x01KúÃ5éÔ\–\aè•Í<Ÿ­îú©õÕ\x1eMñÒ\x1f©*\x02‡œbw\x14\x12E‰\x13×+•È‹ãÛ9÷È\x13mñ\x17\x0f:\x1f\x1f\x10¬ïiêzáÍ\x1cP\x14<p”ùç{»ÙÚå¡F… eœa\x18A¹aB\x16&Cœ+\x12*˜{M»CXY\x17\x15^0Ε'-ÙÜå!§–..ÈzäݯLÕsÔÉfj\x05\x13\x14U\x0eŒ\x06uÏ—ËšåèÈxâá\x11qqTUÊåm˜DŒb\x0f°®7hzèæ‰óñÌš\x1f\x13œIžG˜–\rò›‡Þ·\x0eCœ5Îè\x05ApEû%˜“~&'•1%\x10ŏå(.å¡tå_•ÎÓµFŸ<+Ú\x15÷ï\x1f\x1dŽwšQpN‚UùiœN7#ÕÖ>žÒ\x1cÂ):\x10ï¶çcÊì»TbEß\x19ä>7\x7f#Žwqnrá_uyWò·Ë\x1aÞmqݹŽlh±V$	\f·Û^[wË^[Ès&š]"»»\x171¶6Ü·CW4Y@š“)€ÙUzŽvœ».œnëHÒït\aœay\x01@Pó&æABT“©EÇ891Ï;N„\0“*“§
mÕŽ©0H»Õ¹7Kœª2YÎÑ\x18ÑŠÅp+»¯êý×Ë|“V\r\x18ŒÜŒ¹€é®nW/ʹŒáPo*áI^ZqÚù]îÑFÜšþŽ^n\x14m\x05¿.c^[y\a
ÏÈœ\x01 
ž§l£[JϺÊ\x1egar™E\x0f\rœi!“\x13§\x05û\fškÉW€C5\x05#Q\x12X[\x01rš¡\x12@œ\x12e‹‚rœãŸ:A|®Ãëcœs€\x0f$àæOw^­Ísmr/›ËBeî¹±±”\r ªJÞ·'!ÉÉêÀŸvfƒbÅÎûŒµášún”aArà]W;«sŸ²e?\x1cI+™ÎA#•\x17\x0f=ÒækŠŠ.§ T,naÎéW\bùt¿žüôUùÎœi4èrÉÉ€ß\x13ºPÍ\x05è#˜§$nÚ\x1c•
⮹\x1cÅdXÅ\x18Îè/œu=Û_5ÌSÜlŠç\x12)œ®\x1e¶	\x17\x04‘@HO«ÏœuNî‰\x0erœ®<âr:j\x151s\x17#˜¹\x13^C5\x0f\x13'yO\x10*k‡Û<é•äÖü˜O'·×Í\x0fU,™„q“Ð\x12nv	‡(U€ž£(\x1dA;|éè$\x05\x02wƒœr\v‹Ìng\x04®b\x05\x17\x04ÉŽq;aèY\atcøïzú;.\x17ñØ•òN\x1aS\r	AD%oœ\x1c˜„]øítŒŸnvÜ›\x1c„‡Œï:prŠ\×>žeL~1è(¢ymH‚‘ÀU\x11¹Û_Ã\Žmææ"\x1dÒÉ!'V|÷\x13…jõŽ8ˆÜ¯žhÛšŒðÛú5̓_»¬k\a\vfx˜j «ŸSDF¹\x11s'œsÏñÜ›s§B\x15\x19J#)õùëÕ3‘6\\v§\v‰6Ÿ®œ
ŒØ¹njˆþUÙ~mð{Ž^p›\rAû6óO–|N@÷ïn‘\bçÄÂ8\x14~!ÚÀ+â\x06¡Û0,€¢CF×æ¯-\x16ónû·ï»h*ùŸ{zށ\x10\29­pS\x1f°Šž'9QIS\x17’=ÍÉŒ:\x1cž'çJ¡­r»/ÍÅ\x02¹Ê‹\x11qp9Îr¶ÆÙîæD\x1c×›Ëcy®DɧN\x05R\x1d&~·9\x10ŸX'H_m8GeÁÉz7ÖráNCÝ)g×3—¢ÄÅÃâ]™\x17añÌŠÔϪŒŽW–þZð£oê]*æÜÛà ¹„jT\x06Ás\x17m*ŸlÁ@í&|Ø\x14Q×Ä<Ny+VôiËer&ï­õÎTÍsš£‘\x14|„H…J¥Ÿ,\x06±vÛëmîŒrW¶\x1aÛ~hSŸß\x0e¢Hž\x05UÆï8”ÊAÒ£\x0eù^[ÜN¥Û‘Aöß²]-¬Wԍù*ŠsŠÏ[=“Àð‰úí)ù\a’L«ŽtÏ$ïÕI\x14ôÙIÀ»Õ·ë¡UüCãËXœ\x12»)' H‰¹šœwAÎ\x17rÐslA|ã›y[Šð$Vt3š$œž\N\x14><‹—¡\x15AWrU ¥Ñûè\x17y<§\x10\x12Šøìr\x13<™IÖd*ŸP»nq\x0e	2©…\f €å„ÊРN„òb@˜\x7fžüàÑš
(sšåL\x1d€¥“\x02€W\x0f«ÇžØµÊÑ\MùºQ\x7f/„jGØC˜â?ZÞ²á\x15Ìõ\x02\b.F5 ‡¬q=¶ýf\x1dŠ È(žÈj}~&ˆ¡\x1c90#lÁ¿v.æÙ‘2,š€Ü9¯*æóLëÞ÷†€I\b¯m6:(·$RžÛ`¢KmÑÜ‘•×=°N\\x0fìi;Ð(r)Pe4áBqùXPçe‘r¢AL.ë»ë·/X”*>3Ÿ5É1‹œ·Lso<Ÿ_5|®mòŽ\ÜÆÝ,hØ\îmÌ\x18ä\x0eyÓ;N’L)”ÒN\x147šò\x04‹ç
H\x14Á\x0e\x1e‰\a©0§'8ç\r\x02ì³… =s>Ng`]çºÊ\x17[s¹Þ@á^qê	Ç&\x149Õ\x13…\x01O‰ŽL.\x17\x1c™ùcH)\x10Ò\x04ó!;\x12\x02®Ë;s|ŒyÜÈI†#yÓ±­á\x15\x11¹UÎSÜZå«ÀŸZAv\x14Ùrózä\x05\x05\x0epÕÍ\x18·»­æ«›\x15%F1mÎ\x1aÌÛ\x1ap Ä‰ó÷ïÏc뎇Ǟ\x11wÑ\x0f3Þ¶‡rºMŠLNÓ¥|›žWõ\x0ep)…$4ƒ× (žsÉĆ[Ž©1ÅÊ“\x10Ž\x19Ï*eÀ§Tà$œ\x1dÚä?Y74\x13\x06ybØ/ÇŸz\x0fGÈ{Šö—\x10²²rcÏ“Ý^[õ\x0f"‡«l€àN«¡W"…ÝWç(ˆ¯+wXÜšrìhtãÈwW»»ã\a"€‰”\h –²åÇ2e4˜“)È»NhP™ÙHuò9Ûš°  WÞ!Ü€¹\x13)î°sñ!ÛŸ×N\x14Çãç\aQ§i\x01B\x19\x14Ưå\+ËøzZ6/6÷ºŒØÚw r\x01Î>8œN\rÉŽvœ)™Ž\x14̱˜(\x1f]\x15+Î\x10CÇ5VÆ}^[êsœ[κ
ýìO žÓ°¡;ã-ÓÄó‰ÊNÓÂ=\x1dÐO9‘\x11\ë7g1ûÓ;O)¶mŽG,‚Çpv屈±º]ïå÷Ð]5\x1eˆ˜Ù(“I8ÒaIÁ&“OÊ1È\x13ŽšiÙC\x13€	À\v²å\x051Q;y7“š$\x17y\#Ÿíæ·”C6£o›=Ñc{ºæŠ
抹®\x1a¹s[š7\bªåQ®ncræ,k;¶5\ÑŽhžÍ\ܺSº0\x1fl
äCZƒK÷K¬1\x10ŽAÅP\x05ß\iÓÈ=
`’dœ²\x10é\x01\x1d”š•Q@'CŠ`\ž9\x05*\x01AI&LN'\0žÓ\x0e<îN©\x0eI9

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

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

> do you have any filesystem that is not reiserfs? If yes, could you, as 
> a test, check whether file activities on _that_ file system still 
> cause these lags, or is the lag purely connected to the reiser3 
> filesystem?

i still have little debug info from you to start from: no 
cfs-debug-info.sh output of the problematic workload and no kernel 
.config.

i tried to reproduce your problems based on your existing description: i 
did a lot of reiser3 testing yesterday and i also wrote a 'BKL latency 
simulator' (which does a faux lock_kernel() + unlock_kernel() so that 
the testcode runs into the BKL all the time) - but still this had no 
visible effect on desktop latencies so either i have some subtle 
difference in my setup or this aspect of your workload is not the cause 
of the smoothness problem.

could please give us more debug info and try to simplify the "bad" case 
down to something that can be pinpointed and triggered more exactly? Do 
you see any particular 'ruckle' in the 3D game when you see a smoothness 
problem? Anything that we could clearly label as 'anomalous latency' in 
a tracer output? (in that case i'll send you tracing patches so that we 
can catch a trace of that 'hickup')

You said the imap stuff could be causing the smoothness problem: as a 
debugging thing could you try to renice all the imap activities (imap 
daemon / mailer) to nice +19, does that make the game magically smooth 
again? If yes then this is an indicator that the problem is interaction 
between the game and the imap activities.

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Lee Revell]

On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> Almost all of the Reiser3
> code runs under the BKL, and the only other major kernel infrastructure
> that has BKL dependencies is the TTY code.

Also NFS:

$ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l
94

Lee

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> > Almost all of the Reiser3
> > code runs under the BKL, and the only other major kernel infrastructure
> > that has BKL dependencies is the TTY code.
> 
> Also NFS:
> 
> $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l
> 94

yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses 
the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. 
Almost all of the reiser3 code runs under the BKL on the other hand.

	Ingo

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Trond Myklebust]

On Thu, 2007-08-02 at 13:45 +0200, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > Almost all of the Reiser3
> > > code runs under the BKL, and the only other major kernel infrastructure
> > > that has BKL dependencies is the TTY code.
> > 
> > Also NFS:
> > 
> > $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l
> > 94
> 
> yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses 
> the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. 
> Almost all of the reiser3 code runs under the BKL on the other hand.

We're still working on fixing the NFS case, but as everyone knows,
finding those last few obscure code sections which still depend on BKL
protection can be tedious work...

Trond

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[J. Bruce Fields]

On Wed, Aug 01, 2007 at 10:35:41PM -0400, Lee Revell wrote:
> On 7/31/07, Ingo Molnar <mingo@elte.hu> wrote:
> > Almost all of the Reiser3
> > code runs under the BKL, and the only other major kernel infrastructure
> > that has BKL dependencies is the TTY code.
> 
> Also NFS:
> 
> $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l
> 94

All the file locking code (the nfs-related stuff in fs/lockd/, and also
the vfs code in fs/locks.c) is under the kernel lock.  I doubt it's held
very long unless you have ridiculous numbers of processes requesting
locks on the same file, but I don't know.

--b.

Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

[Ingo Molnar]

* kriko <kristjan.ugrin@gmail.com> wrote:

> I'm trying to get kernel 2.6.22-ck and 2.6.23-rc1 work to test the new 
> cfs scheduler, but I get broken system. Networking is totally broken 
> (cannot find module for my marvell yukon gigabit ethernet in kconfig), 
> firewall / routing doesn't work (a bunch of error messages when 
> firewall script starts). Were there drastic changes in networking 
> support? Currently I'm running 2.6.21-ck1 on opensuse 10.2 and it 
> works fine.

pick up 2.6.22-cfsv19 from:

   http://people.redhat.com/mingo/cfs-scheduler/

2.6.23-rc1 is indeed a bit experimental.

	Ingo

Re: Linus 2.6.23-rc1

[Kasper Sandberg]

(sorry for repost, but there seemed to have been some troubles..)

On Sun, 2007-07-22 at 14:04 -0700, Linus Torvalds wrote:
> Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
> 
> And it has a *ton* of changes as usual for the merge window, way too much 
> for me to be able to post even just the shortlog or diffstat on the 
> mailing list (but I had many people who wanted to full logs to stay 
> around, so you'll continue to see those being uploaded to kernel.org).
> 
> Lots of architecture updates (for just about all of them - x86[-64], arm, 
> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates 
> (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, 
> firewire, i2c, you name it).
> 
> Filesystems, VM, networking, ACPI, it's all there. And virtualization all 
> over the place (kvm, lguest, Xen).
> 
> Notable new things might be the merge of the cfs scheduler, and the UIO 
> driver infrastructure might interest some people.
> 
Im still not so keen about this, Ingo never did get CFS to match SD in
smoothness for 3d applications, where my test subjects are quake(s),
world of warcraft via wine, unreal tournament 2004. And this is despite
many patches he sent me to try and tweak it. As far as im concerned, i
may be forced to unofficially maintain SD for my own systems(allthough
lots in the gaming community is bound to be interrested, as it does make
games lots better)


<snip>

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>
> Im still not so keen about this, Ingo never did get CFS to match SD in
> smoothness for 3d applications, where my test subjects are quake(s),
> world of warcraft via wine, unreal tournament 2004. And this is despite
> many patches he sent me to try and tweak it.

You realize that different people get different behaviour, don't you? 
Maybe not.

People who think SD was "perfect" were simply ignoring reality. Sadly, 
that seemed to include Con too, which was one of the main reasons that I 
never ended entertaining the notion of merging SD for very long at all: 
Con ended up arguing against people who reported problems, rather than 
trying to work with them.

Andrew also reported an oops in the scheduler when SD was merged into -mm, 
so there were other issues.

> As far as im concerned, i may be forced to unofficially maintain SD for 
> my own systems(allthough lots in the gaming community is bound to be 
> interrested, as it does make games lots better)

You know what? You can do whatever you want to. That's kind of the point 
of open source. Keep people honest by having alternatives.

But the the thing is, if you want to do a good job of doing that, here's a 
big hint: instead of keeping to your isolated world, instead of just 
talking about your own machine and ignoring other peoples machines and 
issues and instead of just denying that problems may exist, and instead of 
attacking people who report problems, how about working with them?

That was where the SD patches fell down. They didn't have a maintainer 
that I could trust to actually care about any other issues than his own.

So here's a hint: if you think that your particular graphics card setup is 
the only one that matters, it's not going to be very interesting for 
anybody else. 

[ I realize that this comes as a shock to some of the SD people, but I'm 
  told that there was a university group that did some double-blind 
  testing of the different schedulers - old, SD and CFS - and that 
  everybody agreed that both SD and CFS were better than the old, but that 
  there was no significant difference between SD and CFS. You can try 
  asking Thomas Gleixner for more details. ]

I'm happy that SD was perfect for you. It wasn't for others, and it had 
nobody who was even interested in trying to solve those issues. 

As a long-term maintainer, trust me, I know what matters. And a person who 
can actually be bothered to follow up on problem reports is a *hell* of a 
lot more important than one who just argues with reporters.

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Grzegorz Kulewski]

On Fri, 27 Jul 2007, Linus Torvalds wrote:
> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>>
>> Im still not so keen about this, Ingo never did get CFS to match SD in
>> smoothness for 3d applications, where my test subjects are quake(s),
>> world of warcraft via wine, unreal tournament 2004. And this is despite
>> many patches he sent me to try and tweak it.
>
> You realize that different people get different behaviour, don't you?
> Maybe not.
>
> People who think SD was "perfect" were simply ignoring reality. Sadly,
> that seemed to include Con too, which was one of the main reasons that I
> never ended entertaining the notion of merging SD for very long at all:
> Con ended up arguing against people who reported problems, rather than
> trying to work with them.

I don't really want to keep all that -ck flamewar going but this sum-up is 
a little strange for me:

If Con was thinking SD was "perfect" why he released 30+ versions of it? 
And who knows how many versions of his previous scheduler?

Besides Con always tried to help people and improve his code if some bugs 
or problems were reported. Archives of this list prove that. I reported 
several problems (on list and privately) and all were fixed very fast and 
with very kind responses. I had run -ck for months and years and it was 
always very stable (I remember one broken "stable" version).

I don't know what exactly are you refering to when you say about those 
unaddressed reports but maybe it depends on who was asking, how and to do 
what (for example - purely theoretical one, I don't remember exact emails 
you refering to so I am not saying it happened - stating at the beginning 
that the whole design is unacceptable and interactivity hacks are a 
must-have won't make a friend from any maintainer and for sure lowers his 
desire to get anything fixed for that guy). Or maybe Con had some bad day 
or was depressed. Happens. But I really don't remember Con ignoring too 
many valuable user reports in last 3 years...

And no - I am not thinking that SD was "perfect". Nothing is perfect, 
especially not software. But it was based on months and years of Con's
experience with desktop and gaming workloads and extensively tested in 
similar uses by _many_ others. In nearly all possible desktop 
configurations, with most games and all video drivers. This is why it was 
perfectly designed and tuned for such workloads while still being general 
enough and without any ugly hacks. And because of these tests and Con's 
believe that the desktop is very (most?) important all bugs and problems 
in this area were probably killed long ago. I think even design was 
changed and tuned a little at the early stages to help solve such 
interactivity/dekstop/gaming problems.

So it does not surprise me that CFS is worse in such workloads (at least 
for some people) because I strongly suspect that the number of people who 
played games with current version of CFS is limited to about 5, maybe 10. 
And I also suspect that you (and Ingo) will get many regression reports 
when 2.6.23 is released (and months later too... or maybe you won't 
because users will be to "scared" to report such hard to mensure and 
reproduce "unimportant" bugs). Hopefully such problems when reported will 
be addressed as soon as they can. And hopefully they will be easy enough 
to solve without rewriting or redesigning CFS and causing that way even 
more regressions in other areas. If not people will probably be patching 
O(1) scheduler back privately...


Thanks,

Grzegorz Kulewski

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Jonathan Jessup wrote:
> 
> Linus, there is a complaint about the Linux kernel, this complaint is that
> the Linux kernel isn't giving priorities to desktop interactivity and
> experience. The response on osnews.com etc have shown that there is public
> demand for it too.

No, the response on osnews.com only shows that there are a lot of armchair 
complainers around.

People are suggesting that you'd have a separate "desktop kernel". That's 
insane. It also shows total ignorance of maintainership, and reality. And 
I bet most of the people there haven't tested _either_ scheduler, they 
just like making statements.

The fact is, I've _always_ considered the desktop to be the most important 
part. And I suspect that that actually is true for most kernel developers, 
because quite frankly, that's what 99% of them ends up using. If a kernel 
developer uses Windows for his day-to-day work, I sure as hell wouldn't 
want to have him developing Linux. That has nothing to do with anything 
anti-windows: but the whole "eat your own dogfood" is a very fundamental 
thing, and somebody who doesn't do that shouldn't be allowed to be even 
_close_ to a compiler!

So the whole argument about how kernel developers think that the desktop 
isn't important is totally made-up crap by Con, and then parrotted by 
osnews and other places.

The fact is, most kernel developers realize that Linux is used in 
different places, on different machines, and with different loads. You 
cannot make _everybody_ happy, but you can try to do as good a job as 
possible. And doing "as good a job as possible" very much includes not 
focusing on any particular load.

And btw, "the desktop" isn't actually one single load. It's in fact a lot 
of very different loads, and different people want different things. What 
makes the desktop so interesting is in fact that it shows more varied 
usage than any other niche - and no, 3D gaming isn't "it". 

> Maybe once or twice Con couldn't help or fix an issue but isn't that what
> open source software is all about anyway?

That's not the issue. 

Con wass fixated on one thing, and one thing only, and wasn't interested 
in anythign else - and attacked people who complained. Compare that to 
Ingo, who saw that what Con's scheduler did was good, and tried to solve 
the problems of people who complained.

The ck mailing list is/was also apparently filled with people who all had 
the same issues, which is seriously the *wrong* thing to do. It means that 
any "consensus" coming out of that kind of private list is totally 
worthless, because the people you ask are already in agreement - you have 
a so-called "selection bias", and they just reinforce their own opinions.

Which is why I don't trust mailing lists with a narrow topic. They are 
_useless_. If you cannot get many different people from _different_ areas 
to test your patches, and cannot see the big picture, the end result won't 
likely be very interesting to others, will it?

The fact is, _any_ scheduler is going to have issues. I will bet you 
almost any amount of money that people are going to complain about Ingo's 
scheduler when 2.6.23 is released. That's not the issue: the issue is that 
the exact same thing would have happened with CK too.

So if you are going to have issues with the scheduler, which one do you 
pick: the one where the maintainer has shown that he can maintain 
schedulers for years, can can address problems from _different_ areas of 
life? Or the one where the maintainer argues against people who report 
problems, and is fixated on one single load?

That's really what it boils down to. I was actually planning to merge CK 
for a while. The _code_ didn't faze me.

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Jan Engelhardt]

On Jul 28 2007 10:12, Linus Torvalds wrote:
>
>The fact is, I've _always_ considered the desktop to be the most important 
>part. [...]
>The fact is, most kernel developers realize that Linux is used in 
>different places, on different machines, and with different loads. You 
>cannot make _everybody_ happy, but you can try to do as good a job as 
>possible. And doing "as good a job as possible" very much includes not 
>focusing on any particular load.

You cannot please everybody in the scheduler question, that is clear,
then why not offer dedicated scheduling alternatives (plugsched comes to mind)
and let them choose what pleases them most, and handles their workload best?



	Jan
-- 

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> 
> You cannot please everybody in the scheduler question, that is clear,
> then why not offer dedicated scheduling alternatives (plugsched comes to mind)
> and let them choose what pleases them most, and handles their workload best?

This is one approach, but it's actually one that I personally think is  
often the worst possible choice. 

Why? Because it ends up meaning that you never get the cross-pollination 
from different approaches (they stay separate "modes"), and it's also 
usually really bad for users in that it forces the user to make some 
particular choice that the user is usually not even aware of.

So I personally think that it's much better to find a setup that works 
"well enough" for people, without having modal behaviour. People complain 
and gripe now, but what people seem to be missing is that it's a journey, 
not an end-of-the-line destination. We haven't had a single release kernel 
with the new scheduler yet, so the only people who have tried it are 
either

 (a) interested in schedulers in the first place (which I think is *not* a 
     good subset, because they have very specific expectations of what is 
     right and what is wrong, and they come into the whole thing with that 
     mental baggage)

 (b) people who test -rc1 kernels (I love you guys, but sadly, you're not 
     nearly as common as I'd like ;)

so the fact is, we'll find out more information about where CFS falls 
down, and where it does well,  and we'll be able to *fix* it and tweak it.

In contrast, if you go for a modal approach, you tend to always fixate 
those two modes forever, and you'll never get something that works well: 
people have to switch modes when they switch workloads.

[ This, btw, has nothing to do with schedulers per se. We have had these 
  exact same issues in the memory management too - which is a lot more 
  complex than scheduling, btw. The whole page replacement algorithm is 
  something where you could easily have "specialized" algorithms in order 
  to work really well under certain loads, but exactly as with scheduling, 
  I will argue that it's a lot better to be "good across a wide swath of 
  loads" than to try to be "perfect in one particular modal setup". ]

This is also, btw, why I think that people who argue for splitting desktop 
kernels from server kernels are total morons, and only show that they 
don't know what the hell they are talking about.

The fact is, the work we've done on server loads has improved the desktop 
experience _immensely_, with all the scalability work (or the work on 
large memory configurations, etc etc) that went on there, and that used to 
be totally irrelevant for the desktop.

And btw, the same is very much true in reverse: a lot of the stuff that 
was done for desktop reasons (hotplug etc) has been a _huge_ boon for the 
server side, and while there were certainly issues that had to be resolved 
(the sysfs stuff so central to the hotplug model used tons of memory when 
you had ten thousand disks, and server people were sometimes really 
unhappy), a lot of the big improvements actually happen because somethng 
totally _unrelated_ needed them, and then it just turns out that it's good 
for the desktop too, even if it started out as a server thing or vice 
versa.

This is why the whole "modal" mindset is stupid. It basically freezes a 
choice that shouldn't be frozen. It sets up an artificial barrier between 
two kinds of uses (whether they be about "server" vs "desktop" or "3D 
gaming" vs "audio processing", or anything else), and that frozen choice 
actually ends up being a barrier to development in the long run.

So "modal" things are good for fixing behaviour in the short run. But they 
are a total disaster in the long run, and even in the short run they tend 
to have problems (simply because there will be cases that straddle the 
line, and show some of _both_ issues, and now *neither* mode is the right 
one)

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Diego Calleja]

El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> escribió:

> So "modal" things are good for fixing behaviour in the short run. But they 
> are a total disaster in the long run, and even in the short run they tend 
> to have problems (simply because there will be cases that straddle the 
> line, and show some of _both_ issues, and now *neither* mode is the right 
> one)


I fully agree with this, but plugsched could have avoided this useless "division"
on the topic of SD vs CFS. IMO that counts as an advantage, too ;)

Re: [ck] Re: Linus 2.6.23-rc1

[Jan Engelhardt]

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


On Jul 28 2007 22:51, Diego Calleja wrote:
>El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> escribió:
>
>> So "modal" things are good for fixing behaviour in the short run. But they 
>> are a total disaster in the long run, and even in the short run they tend 
>> to have problems (simply because there will be cases that straddle the 
>> line, and show some of _both_ issues, and now *neither* mode is the right 
>> one)
>
>I fully agree with this, but plugsched could have avoided this useless "division"
>on the topic of SD vs CFS. IMO that counts as an advantage, too ;)
>

It's like CONFIG_HZ - more or less often debated, and now we have everyone
happy by giving them the choice.




	Jan
-- 

Re: [ck] Re: Linus 2.6.23-rc1

[Roland Dreier]

 > It's like CONFIG_HZ - more or less often debated, and now we have everyone
 > happy by giving them the choice.

That's an interesting analogy -- since really the right answer there
seems not to be modal at all, but rather to do CONFIG_NO_HZ.

 - R.

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Diego Calleja wrote:

> El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> escribió:
> > 
> > So "modal" things are good for fixing behaviour in the short run. But they 
> > are a total disaster in the long run, and even in the short run they tend 
> > to have problems (simply because there will be cases that straddle the 
> > line, and show some of _both_ issues, and now *neither* mode is the right 
> > one)
> 
> I fully agree with this, but plugsched could have avoided this useless "division"
> on the topic of SD vs CFS. IMO that counts as an advantage, too ;)

Sure. I actually think it's a huge advantage (see the ManagementStyle file 
on pissing people off), but at the same time, I don't like playing 
politics with technology. The kernel is a technical project, and I make 
technical decisions.

So I absolutely detest adding code for "political" reasons.

I personally feel that modal behaviour is bad, so it would introduce what 
is in my opinion bad code, and likely result in problems not being found 
and fixed as well (because people would pick the thing that "works for 
them", and ignore the problems in the other module). So while I don't like 
making irreversible decisions (and the choice of CFS wasn't irreversible 
in itself, but if it pisses off Con, _that_ is generally not reversible), 
I dislike even more making a half-assed decision.

So rather than making a choice at all, my other choice would have been to 
not merge _either_ scheduler, and let people just continue to fight it 
out. Would that have made people happier? I seriously doubt it.

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Alex Besogonov]

Linus Torvalds wrote:
> I personally feel that modal behaviour is bad, so it would introduce what 
> is in my opinion bad code, and likely result in problems not being found 
> and fixed as well (because people would pick the thing that "works for 
> them", and ignore the problems in the other module). 
I'm sorry, but this argument doesn't hold water. It was invoked years 
ago and turned out to be incorrect - the new CFS scheduler is not just a
fixed old scheduler, it's a completely redesigned one.

-- 
With respect,
             Alex Besogonov (cyberax@elewise.com)

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

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

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Diego Calleja wrote:
> > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds 
<torvalds@linux-foundation.org> escribió:
> > > So "modal" things are good for fixing behaviour in the short run.
> > > But they are a total disaster in the long run, and even in the
> > > short run they tend to have problems (simply because there will be
> > > cases that straddle the line, and show some of _both_ issues, and
> > > now *neither* mode is the right one)
> >
> > I fully agree with this, but plugsched could have avoided this
> > useless "division" on the topic of SD vs CFS. IMO that counts as an
> > advantage, too ;)
>
> Sure. I actually think it's a huge advantage (see the ManagementStyle
> file on pissing people off), but at the same time, I don't like playing
> politics with technology. The kernel is a technical project, and I make
> technical decisions.

IMHO thats an illusion. The kernel has become a community project pretty 
soon after you have released it initially. And the community members are 
human beings. Thus while the kernel source code in itself for sure 
describes technical processes, the kernel is more than just a technical 
project.

> So I absolutely detest adding code for "political" reasons.

I can understand this and I agree to it, cause it would mean fixing 
political things on technical grounds and thus not fixing them at all.

> I personally feel that modal behaviour is bad, so it would introduce
> what is in my opinion bad code, and likely result in problems not being
> found and fixed as well (because people would pick the thing that
> "works for them", and ignore the problems in the other module). So
> while I don't like making irreversible decisions (and the choice of CFS
> wasn't irreversible in itself, but if it pisses off Con, _that_ is
> generally not reversible), I dislike even more making a half-assed
> decision.

I agree to this to some extent. But if the mainline kernel does not 
contain suitable solutions for one subsystem people will tend to plug in 
other solutions that work for them even where there is no boot or runtime 
plugability.

I have been using TuxOnIce (formerly suspend2) for quite some time and 
didn't even try the in-kernel-suspend-to-disk stuff since quite some 
kernel versions since I could not have been bothered anymore after it was 
failing back then.

So when there are two different approaches with good following it may have 
be good to have some plugability for testing things. But it may be 
difficult to remove it afterwards again..., but it would still be 
possible to remove plugins that are only used rarely and they how the 
other ones evolve.

> So rather than making a choice at all, my other choice would have been
> to not merge _either_ scheduler, and let people just continue to fight
> it out. Would that have made people happier? I seriously doubt it.

I tried speaking to Con and Ingo whether they could settle their issue 
with one another and work together. In *private* mails, away from all the 
flame throwing.

Actually I believe that human things should be resolved on the human side, 
not on the technical one. And as I perceive no serious attempt has been 
made on that - except my own maybe.

Maybe just writing an email to both Con and Ingo where you told both of 
them your concerns and thoughts would have helped a lot. A

"Hi Con and Ingo, 

Con, I do not believe that you are able to maintain SD for reason 1,2 and 
3. But I do think that Ingo could. But I think, that you wrote great code 
and brought in good scheduler concepts and ideas to the Linux world. Now 
Ingo has CFS and you have SD... could there be a way for you to stay 
involved with scheduler issues and work together with Ingo? If so how 
could it look like?

Ingo, do you see areas where Con can help you with? Are there things in SD 
that you would like to have in CFS? Do you see a way to work with Con 
together on the scheduler?"

(just a draft;-)

for example. It would have given Con some recognition for his work. It 
could have helped to address the political, well not even the political, 
but the human issue here. I believe that this is what Con missed the 
most: Getting some form of recognition from the "official" kernel people! 
I tried to give some recognition, but I am "just" a user of his patches.

Would that have been difficult for you to write, Linus?

Its not too late for giving Con some recognition. A simple 

"Hi Con, 

I am sorry that you decided to leave kernel development. I felt I had to 
make a decision about the scheduler thing and these where my concerns...

I just wanted to tell you that I did not mean any personal offence with 
you and did not have any real issue with your code at all, 

Regards Linus" 

as an aftermath could still help. Just a little gesture maybe - but it can 
make a big difference. Maybe without even asking him to come back... I 
think Con made his decision for now at least.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

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

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> > You cannot please everybody in the scheduler question, that is clear,
> > then why not offer dedicated scheduling alternatives (plugsched comes
> > to mind) and let them choose what pleases them most, and handles
> > their workload best?

[...]

> So I personally think that it's much better to find a setup that works
> "well enough" for people, without having modal behaviour. People
> complain and gripe now, but what people seem to be missing is that it's
> a journey, not an end-of-the-line destination. We haven't had a single
> release kernel with the new scheduler yet, so the only people who have
> tried it are either
>
>  (a) interested in schedulers in the first place (which I think is
> *not* a good subset, because they have very specific expectations of
> what is right and what is wrong, and they come into the whole thing
> with that mental baggage)
>
>  (b) people who test -rc1 kernels (I love you guys, but sadly, you're
> not nearly as common as I'd like ;)
>
> so the fact is, we'll find out more information about where CFS falls
> down, and where it does well,  and we'll be able to *fix* it and tweak
> it.

I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 
had interruptions in music playback initially even though the machine was 
idling - while at the same time music playback was perfectly fine with SD 
since quite some iterations. After quite some iterations of testing new 
CFS versions from Ingo it started working like I think it should. 

Expecting a interruption free music playback IMO by no way is any mental 
baggage. I for sure am interested in schedulers, but actually I do not 
understand the exact principles by with SD and CFS work, I just had no 
time to look at them closer, and thus just looked at: How does it behave 
on my laptops with different desktop loads? Actually from a technical 
point of view I do not care whether CFS or SD goes in, cause I simply 
understand enough of the technical concepts behind them. And since they 
are behaving roughly the same on my laptops now I have no issue with CFS 
going in from a functional view. It seems to do what I expect from a 
scheduler and I am happy with that.

While I have nothing against CFS in the kernel, I actually do not like the 
way the decision was done and how it was communicated. Its not the 
outcome of the decision but the way it was done that bothers me. I 
actually also think that the communication between Ingo and Con could 
have been better especially when Ingo decided to write CFS while Con was 
still working hard on SD.

I do think that it would not have been necessary to loose Con's talent. 
Sure I think that Con had its share in it, but it does not make sense to 
concentrate on his share, cause only he can do that and he is gone for 
now. But thats exactly what I perceive you are doing. 

And I realize it doesn't make sense for me at all to concentrate at your 
or Ingo's share. I made my point and unless you Ingo and the others 
involved decide to look at whether there might be something you have done 
that has contributed to loosing the talent of a good kernel developer the 
issue can't be helped. Unless people decide to look at themselves instead 
of pointing out what in their eyes has been wrong with others, the issue 
will stand still.

I am pretty confident that SD in the kernel would have been a viable 
choice as well and that Con would have done his best to support and 
maintain it. Well now thats history. Con decided to stay out of kernel 
development and I actually can understand him.

I believe it is possible to learn something out of how this all happened. 
And actually I merely wanted to point this out to you. Whether you decide 
to learn something out of it or not, actually is your choice. 

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Sam Ravnborg]

> I 
> actually also think that the communication between Ingo and Con could 
> have been better especially when Ingo decided to write CFS while Con was 
> still working hard on SD.

You realize that Ingo posted his code for anyone to look at/comment at
about 48 hours after he started to work on CFS?

	Sam

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > I
> > actually also think that the communication between Ingo and Con could
> > have been better especially when Ingo decided to write CFS while Con
> > was still working hard on SD.
>
> You realize that Ingo posted his code for anyone to look at/comment at
> about 48 hours after he started to work on CFS?

Yes.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: [ck] Re: Linus 2.6.23-rc1

[Sam Ravnborg]

On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > I
> > > actually also think that the communication between Ingo and Con could
> > > have been better especially when Ingo decided to write CFS while Con
> > > was still working hard on SD.
> >
> > You realize that Ingo posted his code for anyone to look at/comment at
> > about 48 hours after he started to work on CFS?
> 
> Yes.
So whats wrong then?
Ingo decides to do a better scheduler - to some extent inspired by Con's work.
And after 48 hours he publish first version that _anyone_ can see and comment on.
Whats wrong with that?

Did you expect some lengthy discussion before the coding phase started or what?

Just trying to understand what you are arguing about.

	Sam

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

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

Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > > I
> > > > actually also think that the communication between Ingo and Con
> > > > could have been better especially when Ingo decided to write CFS
> > > > while Con was still working hard on SD.
> > >
> > > You realize that Ingo posted his code for anyone to look at/comment
> > > at about 48 hours after he started to work on CFS?
> >
> > Yes.
>
> So whats wrong then?
> Ingo decides to do a better scheduler - to some extent inspired by
> Con's work. And after 48 hours he publish first version that _anyone_
> can see and comment on. Whats wrong with that?
>
> Did you expect some lengthy discussion before the coding phase started
> or what?
>
> Just trying to understand what you are arguing about.

If I tried to rewrite a kernel subsystem - should I ever happen to dig 
that deep into kernel matters - while I actually know that someone 
already spent countless hours on exactly rewriting the exact same 
subsystem, I think I would have told that other developer about it as 
soon as I started coding on it. And if it just was a

"Hi Con,

I reconsidered the scheduling ideas again you brought to the Linux kernel 
world. Instead of using your scheduler tough I like to try to write a new 
one with fairness in mind, cause I think this, this and this can be 
improved upon.

I would like to hear your ideas about that as soon as possible and would 
like you to contribute your ideas and also code, where you see hit. You 
can find the git / bazaar / whatever repository where I do my 
developments at: someurl.

Regards, Ingo"

I believe that Ingo did not meant any bad at all. I think its just the way 
he works, he likes to have code before saying anything. But still I 
believe before I'd go about replacing someone else code completely I 
would inform that developer beforehand, even if it then turns out not to 
be feasible at all. No need to anounce it to the world already, but I 
would have informed that developer.

And aside from that there has been communication before and after this 
event that IMHO could have been "better". And thats not only targetted at 
Ingo.

A view this whole issue as "everyone who was involved in it, actually was 
involved in it and has his share in its outcome". So everyone has a great 
chance to learn something out of it. (That includes me of course, too.)

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Satyam Sharma]

Hi Martin,


On Sun, 29 Jul 2007, Martin Steigerwald wrote:

> Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > > > I
> > > > > actually also think that the communication between Ingo and Con
> > > > > could have been better especially when Ingo decided to write CFS
> > > > > while Con was still working hard on SD.
> > > >
> > > > You realize that Ingo posted his code for anyone to look at/comment
> > > > at about 48 hours after he started to work on CFS?
> > >
> > > Yes.
> >
> > So whats wrong then?
> > Ingo decides to do a better scheduler - to some extent inspired by
> > Con's work. And after 48 hours he publish first version that _anyone_
> > can see and comment on. Whats wrong with that?
> >
> > Did you expect some lengthy discussion before the coding phase started
> > or what?
> >
> > Just trying to understand what you are arguing about.
> 
> If I tried to rewrite a kernel subsystem - should I ever happen to dig 
> that deep into kernel matters - while I actually know that someone 
> already spent countless hours on exactly rewriting the exact same 
> subsystem, I think I would have told that other developer about it as 
> soon as I started coding on it. And if it just was a
> 
> "Hi Con,
> 
> I reconsidered the scheduling ideas again you brought to the Linux kernel 
> world. Instead of using your scheduler tough I like to try to write a new 
> one with fairness in mind, cause I think this, this and this can be 
> improved upon.
> 
> I would like to hear your ideas about that as soon as possible and would 
> like you to contribute your ideas and also code, where you see hit. You 
> can find the git / bazaar / whatever repository where I do my 
> developments at: someurl.
> 
> Regards, Ingo"

Sending out the code (and early enough, 48 hours /is/ early enough) *is*
the normal (and good) way to do exactly the communication you described
above, IMHO.

> I believe that Ingo did not meant any bad at all. I think its just the way 
> he works, he likes to have code before saying anything. But still I 
> believe before I'd go about replacing someone else code completely I 
> would inform that developer beforehand, even if it then turns out not to 
> be feasible at all. No need to anounce it to the world already, but I 
> would have informed that developer.

IMHO, what you're suggesting is: (1) not the way development normally
happens in Linux, and, (2) not the way it /should/ happen, either. If
there's something (subsystem, any code big or small) I think I can do
better or have an idea for, I /should/ be able to just hack on it a bit
and then send it out so everybody can comment on it. Why should I be
forced to dance/discuss around with some other people, when the faster
and more effective way would be just present the code/patch that I
have in my mind as an RFC?

See, Martin, in the end it's not about developer A vs developer B. It's
about making the kernel the best out there -- that's what the users want,
anyway. Yes, I fully understand (and have said so earlier myself) that
there's a very important "social" aspect to development on such projects,
but it's best if developer B understands that this is the way things do
(and should) happen and adapt to it. [ It's not like I've been around for
long, however, but the above is still my opinion, fwiw. ]

Satyam

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

Am Sonntag 29 Juli 2007 schrieb Satyam Sharma:
> Hi Martin,

Hi Satyam,

> > I believe that Ingo did not meant any bad at all. I think its just
> > the way he works, he likes to have code before saying anything. But
> > still I believe before I'd go about replacing someone else code
> > completely I would inform that developer beforehand, even if it then
> > turns out not to be feasible at all. No need to anounce it to the
> > world already, but I would have informed that developer.
>
> IMHO, what you're suggesting is: (1) not the way development normally
> happens in Linux, and, (2) not the way it /should/ happen, either. If
> there's something (subsystem, any code big or small) I think I can do
> better or have an idea for, I /should/ be able to just hack on it a bit
> and then send it out so everybody can comment on it. Why should I be
> forced to dance/discuss around with some other people, when the faster
> and more effective way would be just present the code/patch that I
> have in my mind as an RFC?

Hmmm, that email would have taken how long? 5 minutes maybe?

I just feel that I would have written it if I happen to know that another 
developer spent lots of time and effort into a subsystem I plan to 
rewrite. Its just human logic to me. Especially when I happen to know 
that the other developer may be new to the kernel development process as 
I know it from a internal view point.

The current kernel development process tries to pretend that there is no 
human involvement. Which is plain inaccurate: It is *all* human 
involvement, without a human not a single bit of kernel code would 
change.

I always believed that kernel developers are human beings and no robots. 
And thus the kernel development process IMHO should be designed with 
human developers in mind instead of robots which take no offence out of 
anything. Otherwise things like what happened here will happen again and 
again and again and talent is lost.

It is damn good to take technical merits into full account! But ignoring 
human aspects of development actually will hinder this. Cause then in the 
end its not about technical merits anymore that do the decision, but that 
human aspects that have been ignored and are floating around 
unconsiously.

Actually I do believe that this discussion already took more resources 
than actually writing a few more mails and doing a bit more communication 
here and there... IMHO the fact that this discussion exists already shows 
that something in the process of submitting kernel patches and supporting 
involvement in kernel development can be improved upon.

> See, Martin, in the end it's not about developer A vs developer B. It's
> about making the kernel the best out there -- that's what the users
> want, anyway. Yes, I fully understand (and have said so earlier myself)
> that there's a very important "social" aspect to development on such
> projects, but it's best if developer B understands that this is the way
> things do (and should) happen and adapt to it. [ It's not like I've
> been around for long, however, but the above is still my opinion, fwiw.
> ]

I am not saying that developer B (Con) does not have his share in how it 
all happened. As written before I got the impression that Con reacted 
hurt where from my point of view no offence was meant - and I told him 
that. But from what I know it would have been possible to actually deal 
with that quite a bit better than has happened. And it would not have 
taken much effort. Well actually I think it would have been quite easy to 
take the talent that has offered itself.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: [ck] Re: Linus 2.6.23-rc1

[Carlo Florendo]

Martin Steigerwald wrote:
> The current kernel development process tries to pretend that there is no 
> human involvement. Which is plain inaccurate: It is *all* human 
> involvement, without a human not a single bit of kernel code would 
> change.

IMHO, the above statements are all plain conjectures. How could you assert 
that the kernel development process is without human development?

If you've followed the list for a while, you'd realize that the list is 
very human.  The fact that flames fly and abound, and the fact that 
individual persons tend to be very strong with respect to their opinions 
indicate that there is a rather high level of human dealings that happen on 
the list.

And I think you are digressing from the main issue, which is the empirical 
comparison of SD vs. CFS and to determine which is best.   The root of all 
the scheduler fuss was the emotional reaction of SD's author on why his 
scheduler began to be compared with CFS.

We obviously all saw how the particular authors tried to address the 
issues.  Ingo tried to address all concerns while Con simply ranted about 
his scheduler being better.  If this is what you think about being a bit 
more human, then I think that this has no place in the lkml.

We've all heard the "show me the numbers" argument, and as far as I can 
see, CFS now fairs much better than SD.

That's the issue.  The best one will emerge to be at the top.  From several 
months of tests and improvements, it seems CFS is emerging to be the better 
scheduler.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: [ck] Re: Linus 2.6.23-rc1

[Bill Huey]

On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
> And I think you are digressing from the main issue, which is the empirical 
> comparison of SD vs. CFS and to determine which is best.   The root of all 
> the scheduler fuss was the emotional reaction of SD's author on why his 
> scheduler began to be compared with CFS.

Legitimate emotional reaction for being locked out of the development
process. There's a very human aspect to this, yes, a negative human
aspect that pervade Linux kernel development and is overly defensive and
protective of new ideas.

> We obviously all saw how the particular authors tried to address the 
> issues.  Ingo tried to address all concerns while Con simply ranted about 
> his scheduler being better.  If this is what you think about being a bit 
> more human, then I think that this has no place in the lkml.

That's highly inaccurate and rather disrespect of Con's experience.
There as a policy decision made with SD that one person basically didn't
like, this person whined like a baby for the a formula bottle and didn't
understand how to use "nice" to control this inherent behavior of this
scheduler.

bill

Re: [ck] Re: Linus 2.6.23-rc1

[Mike Galbraith]

On Tue, 2007-07-31 at 02:57 -0700, Bill Huey wrote:
> On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
> >
> > We obviously all saw how the particular authors tried to address the 
> > issues.  Ingo tried to address all concerns while Con simply ranted about 
> > his scheduler being better.  If this is what you think about being a bit 
> > more human, then I think that this has no place in the lkml.
> 
> That's highly inaccurate and rather disrespect of Con's experience.
> There as a policy decision made with SD that one person basically didn't
> like, this person whined like a baby for the a formula bottle and didn't
> understand how to use "nice" to control this inherent behavior of this
> scheduler.

Chuckle.  You are really desperate for entertainment.

	-Mike

Re: [ck] Re: Linus 2.6.23-rc1

[Carlo Florendo]

Bill Huey (hui) wrote:
> On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
>> And I think you are digressing from the main issue, which is the empirical 
>> comparison of SD vs. CFS and to determine which is best.   The root of all 
>> the scheduler fuss was the emotional reaction of SD's author on why his 
>> scheduler began to be compared with CFS.
> 
> Legitimate emotional reaction for being locked out of the development
> process. There's a very human aspect to this, yes, a negative human
> aspect that pervade Linux kernel development and is overly defensive and
> protective of new ideas.

Yes, the reaction was legitimate but it could have been better.  It would 
have benefited everyone if instead of posting rants, numbers and patches or 
suggested solutions were posted.  Up until today, some posters that 
complain on how CFS fairs worse than SD simply post reports that say:

"I use this system in this way and it does not fair well with cfs!"

Look at this one for example:

http://lkml.org/lkml/2007/7/31/199

It looks technical but it isn't.

The author simply stated that he built his own lightweight Linux box that 
specializes in audio but there has not been any technical characteristic of 
the problem.  We don't even know the audio libraries he's using but simply 
claimed that he wrote his own.

The report, if I were the one to debug it, is completely useless since it 
does not even give some reproducability hints nor technical characteristics 
of the system.

This is what some of the SD fan-boys do.  Rant.

Thank you very much.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: [ck] Re: Linus 2.6.23-rc1

[Ingo Molnar]

* Satyam Sharma <satyam@infradead.org> wrote:

> > > So whats wrong then?
> > > 
> > > Ingo decides to do a better scheduler - to some extent inspired by 
> > > Con's work. And after 48 hours he publish first version that 
> > > _anyone_ can see and comment on. Whats wrong with that?
> > >
> > > Did you expect some lengthy discussion before the coding phase 
> > > started or what?
> > >
> > > Just trying to understand what you are arguing about.
> > 
> > If I tried to rewrite a kernel subsystem - should I ever happen to 
> > dig that deep into kernel matters - while I actually know that 
> > someone already spent countless hours on exactly rewriting the exact 
> > same subsystem, I think I would have told that other developer about 
> > it as soon as I started coding on it. And if it just was a
> > 
> > "Hi Con,
> > 
> > I reconsidered the scheduling ideas again you brought to the Linux 
> > kernel world. Instead of using your scheduler tough I like to try to 
> > write a new one with fairness in mind, cause I think this, this and 
> > this can be improved upon.
> > 
> > I would like to hear your ideas about that as soon as possible and 
> > would like you to contribute your ideas and also code, where you see 
> > hit. You can find the git / bazaar / whatever repository where I do 
> > my developments at: someurl.
> > 
> > Regards, Ingo"
> 
> Sending out the code (and early enough, 48 hours /is/ early enough) 
> *is* the normal (and good) way to do exactly the communication you 
> described above, IMHO.

yeah. And note that the time from the "ok, this approach might work" 
point to releasing CFS was even less than the original ~62 hours of CFS 
development.

I dont typically write code because i'm particularly "convinced" about 
an idea or because i "believe in" an idea, i mostly write code to 
_check_ whether an idea is worth advancing or not. Writing code is my 
form of "thinking", and releasing patches is my form of telling others 
about my "thoughts". I might have guesses about how well something will 
work out in practice (and i'd certainly be a fool to go out coding 
blindly), but surprises happen almost always, both in positive and in 
negative direction, and even with relatively simple patches.

CFS started out as an experiment to simplify the scheduler, to clean up 
the after-effects of a better-desktop-scheduling patch Mike Galbraith 
sent me. Had anyone told me at that time that i'd end up writing a new 
scheduler i'd have laughed at the suggestion and i'd have pointed to the 
large number of pending patches of mine in forms of the -rt tree, the 
syslet/threadlet code and other stuff that needs fixing a lot more 
urgent than the task scheduler.

During that cleanup work did i realize how a policy-modularized 
scheduler would allow the bridging of the seemingly unreconcilable 
friction between the O(1) data structures that things like RT scheduling 
needs and the binary tree that "fair share scheduling" concepts dictate. 
(most of the complexity in kernel code like the scheduler derives from 
complexity in data structures, so you start writing code by thinking 
about your data structures.)

And the time from the point where i thought "ok, this fair-share thing 
behaves pretty well and it certainly looks simpler than the current 
code" to the announcement on lkml was more on the order of hours than 
days - much of the 62 hours were spent on ripping out the old code and 
on getting the new design up and running.

There was simply no code in existence before CFS which has proven the 
code simplicity/design virtues of 'fair scheduling' - SD was more of an 
argument _against_ it than for it. I think maybe even Con might have 
been surprised by that simplicity: in his first lkml reaction to CFS he 
also wrote that he finds the CFS code "beautiful":

  http://lkml.org/lkml/2007/4/14/199

and my reply to Con's mail:

  http://lkml.org/lkml/2007/4/15/64

still addresses a good number of points raised in this thread i think.

	Ingo

Re: [ck] Re: Linus 2.6.23-rc1

[Sam Ravnborg]

On Sun, Jul 29, 2007 at 08:23:31PM +0200, Martin Steigerwald wrote:
> Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote:
> > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > > > > I
> > > > > actually also think that the communication between Ingo and Con
> > > > > could have been better especially when Ingo decided to write CFS
> > > > > while Con was still working hard on SD.
> > > >
> > > > You realize that Ingo posted his code for anyone to look at/comment
> > > > at about 48 hours after he started to work on CFS?
> > >
> > > Yes.
> >
> > So whats wrong then?
> > Ingo decides to do a better scheduler - to some extent inspired by
> > Con's work. And after 48 hours he publish first version that _anyone_
> > can see and comment on. Whats wrong with that?
> >
> > Did you expect some lengthy discussion before the coding phase started
> > or what?
> >
> > Just trying to understand what you are arguing about.
> 
> If I tried to rewrite a kernel subsystem - should I ever happen to dig 
> that deep into kernel matters - while I actually know that someone 
> already spent countless hours on exactly rewriting the exact same 
> subsystem, I think I would have told that other developer about it as 
> soon as I started coding on it.
The usual way to communicate such things on lkml are with patches as also
happened in this case.
It's not like Ingo had secretly developing a scheduler in parallel for
weeks or months but.
But I assume all the fuzz is about something else - it cannot be about
a these 48 hours - I hope..

Enough on this - back to work.

	Sam

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:

> People are suggesting that you'd have a separate "desktop kernel".
> That's insane. It also shows total ignorance of maintainership, and
> reality. And I bet most of the people there haven't tested _either_
> scheduler, they just like making statements.

Ok, hands up again.

I tested both schedulers. And I know a lot of people from the ck patchset 
mailing list did, despite its narrow ck patchset related topic

> The fact is, I've _always_ considered the desktop to be the most
> important part. And I suspect that that actually is true for most
> kernel developers, because quite frankly, that's what 99% of them ends
> up using. If a kernel developer uses Windows for his day-to-day work, I
> sure as hell wouldn't want to have him developing Linux. That has
> nothing to do with anything anti-windows: but the whole "eat your own
> dogfood" is a very fundamental thing, and somebody who doesn't do that
> shouldn't be allowed to be even _close_ to a compiler!
>
> So the whole argument about how kernel developers think that the
> desktop isn't important is totally made-up crap by Con, and then
> parrotted by osnews and other places.

Ah, well. So where for example is a working, fast and reliable snapshot 
solution despite of one being available for *years*? And no, suspend to 
ram just doesn't cut it - its a complete nonsense for my laptop usage 
pattern.

> And btw, "the desktop" isn't actually one single load. It's in fact a
> lot of very different loads, and different people want different
> things. What makes the desktop so interesting is in fact that it shows
> more varied usage than any other niche - and no, 3D gaming isn't "it".

3D gaming was only *one* workload that people where happy with when 
running SD.

> Con wass fixated on one thing, and one thing only, and wasn't
> interested in anythign else - and attacked people who complained.
> Compare that to Ingo, who saw that what Con's scheduler did was good,
> and tried to solve the problems of people who complained.

One thing? How about

1) various improvements to VM stuff and
2) swap prefetch?
3) pluggable schedulers?

And various other patch sets. 

Con concentrated on Desktop performance thats right, but even there he 
didn't stop. Did you know for example that Con maintained a server 
related ck patchset for years as well?

Where actually is that "Con concrentates only on one thing"?

> The ck mailing list is/was also apparently filled with people who all
> had the same issues, which is seriously the *wrong* thing to do. 

Just one question: Did you actually look there *before* making above 
statement? Can you give a honest answer to this question?

> So if you are going to have issues with the scheduler, which one do you
> pick: the one where the maintainer has shown that he can maintain
> schedulers for years, can can address problems from _different_ areas
> of life? Or the one where the maintainer argues against people who
> report problems, and is fixated on one single load?

Do you have any concrete example? I have only one, one out of countless 
responses of Con to people how reported problems: The X11 renice issue.

If I requested from Ingo to make a scheduler exception that contradicts 
the design of CFS and I could not convince Ingo that this exception 
really does make sense, I think I will get into a discussion with Ingo - 
and exactly that makes perfect sense to me! Actually Ingo did have 
renicing for X and kernel threads in CFS for quite a while as well.

Still that said, I admit that the tone may well have played a role here - 
as it does in this discussion as well. Maybe Con reacted hurt where no 
offence was meant at times. But we are all humans, and given all the 
unfriendlyness Con apparently faced I can understand this. "survival of 
the fittest maintainer"? Maybe. But I invite you to listen on the last 
results in biological reasons: Darwins "survival of the fitttest" is only 
one principle and doesn't explain how lifing beings put themselves 
together at all. Biologist find out more and more than the genome is no 
command central at all, but being used by living beings in the way their 
complex parts being interacting with one another see fit.

One should take the tone in this discussion into account. Cause now one 
can argue that Con doesn't want to maintain the SD scheduler. Well thats 
true, but once he was more than willing to do that and IMHO he reacted to 
at least most problem reports in a very professional manner. Maybe not to 
100% of them, but can you actually say that from Ingo? From what I seen 
Ingo also is a human...

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: [ck] Re: Linus 2.6.23-rc1

[Tomas Carnecky]

Linus Torvalds wrote:
> The fact is, I've _always_ considered the desktop to be the most important 
> part. And I suspect that that actually is true for most kernel developers, 
> because quite frankly, that's what 99% of them ends up using. If a kernel 
> developer uses Windows for his day-to-day work, I sure as hell wouldn't 
> want to have him developing Linux. That has nothing to do with anything 
> anti-windows: but the whole "eat your own dogfood" is a very fundamental 
> thing, and somebody who doesn't do that shouldn't be allowed to be even 
> _close_ to a compiler!

That comes from someone whose desktop is a dual CPU Mac with how much 
RAM? 4GB? That can hardly be regarded as the average desktop computer. 
You cannot have computers with heaps of CPU/RAM and claim that you know 
how a Linux feels on a 'normal' desktop. That simply doesn't add up. So 
please stop saying that you're 'eating your own dogfood'. Sure, there 
may be kernel developers who actually test the kernels on older 
computers, but don't tell us that you're using those for your daily work.

That being said, I can't but agree with Con what he said in his recent 
interview, namely that some kernel developers are out of touch with the 
'normal' desktop users who have a bit slower machines (Linus, if you 
indeed use a desktop computer like I described above then this also 
applies to you). And I can't imagine that any of you have done such 
intensive tests of desktop responsiveness etc. like Con did. By all 
means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS 
vs. CD' flamewar, but I simply can't let your statement leave unanswered.

tom

Re: [ck] Re: Linus 2.6.23-rc1

[Matthew Hawkins]

On 7/28/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> People who think SD was "perfect" were simply ignoring reality. Sadly,
> that seemed to include Con too, which was one of the main reasons that I
> never ended entertaining the notion of merging SD for very long at all:
> Con ended up arguing against people who reported problems, rather than
> trying to work with them.

Not even Con thought SD was perfect, so this is being more than a
little dishonest.
One of his parting comments on the ck list was a list of things that
could be fixed/improved.

My experience is vastly different to yours, perhaps because I have
been subscribed to his mailing list for many years (too many to count)
and have run his patchset in various environments in that period - and
you have not.  Con was always very helpful to people experiencing
problems and did in fact work with them to get them resolved.  The
list is web-archived so everyone is free to go see that for
themselves.  He also tried to get others interested and involved in
kernel development at large.  SD itself went through 46 revisions
because of things people encountered using it, and it would have been
more still considering what Con had in the works had he not been
pushed out.

I can see how on LKML your viewpoint differs, though to be fair in my
recollection there was only one person Con argued with, and that man
is a belligerent troll.  Its my honest opinion that the problems that
troll encountered were completely made up, which is backed by the
evidence that no-one else had encountered or indeed could even
reproduce them.  I recall Con himself catching the troll out in a
lie-based "proof" on one occasion.  I'll hunt gmane for the link as I
believe people like that need to be exposed and stopped.  There
certainly was a lot of hot air and handwaving, and now that one other
tiny portion of Con's work has been raised its still going on.  Its
interesting that the same cycle repeats even when Con is no longer
involved, which proves Con could not have been the issue.

I'm sorry you in particular haven't been able to have the same
experience with Con as so many others have, especially considering who
you are and the weight your words have.  You've lost a really great
asset and aren't even aware of it.  That's really sad for everyone.

(fwiw the -ck list did a lot of the testing for CFS recently, and over
the years various other things too.  Generally a good bunch of folks
keen to try anything to make their Linux experience better.  And
definitely devoid of these petty politics and egos that are plagueing
other Linux-related lists.  You've not only lost Con, but perhaps one
of the better testbeds also).

-- 
Matt

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

Am Samstag 28 Juli 2007 schrieb Matthew Hawkins:
> On 7/28/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > People who think SD was "perfect" were simply ignoring reality.
> > Sadly, that seemed to include Con too, which was one of the main
> > reasons that I never ended entertaining the notion of merging SD for
> > very long at all: Con ended up arguing against people who reported
> > problems, rather than trying to work with them.
>
> Not even Con thought SD was perfect, so this is being more than a
> little dishonest.
> One of his parting comments on the ck list was a list of things that
> could be fixed/improved.
[...]
> I'm sorry you in particular haven't been able to have the same
> experience with Con as so many others have, especially considering who
> you are and the weight your words have.  You've lost a really great
> asset and aren't even aware of it.  That's really sad for everyone.
>
> (fwiw the -ck list did a lot of the testing for CFS recently, and over
> the years various other things too.  Generally a good bunch of folks
> keen to try anything to make their Linux experience better.  And
> definitely devoid of these petty politics and egos that are plagueing
> other Linux-related lists.  You've not only lost Con, but perhaps one
> of the better testbeds also).

I fully agree to this. Being part of the ck mailing list community was fun 
and I really appreciate the friendly and supporting tone here. From the 
mails I ever read from the LKML - I do not read it regularily at all - I 
got the impression that its members can learn *a lot* from the ck mailing 
list community. And also from the TuxOnNice mailing list community.

For example on how to encourage users to send in their feedback and test 
kernel subsystems. And from what I heard again and again its exactly 
testing that is lacking to a great degree.

Actually even CFS was helped by the ck mailinglist community.

The tone on the ck mailinglist community encouraged me to compile kernel 
patches, try out latest ck patchsets and then when CFS could not do the 
same smooth music playback on my Amarok machine than SD try out a ton of 
patches from Ingo Molnar to get those regressions (compared to SD) fixed.

But all the times I stayed away from LKML and still do not feel that much 
motivation to read in it regularily. Actually my own perceptions matches  
what Con said in his goodbye interview[1]: It *scares* me away. Its this 
elitist "I know it better than you and what do you want anyway" that in 
my eyes demotivate a lot of users to bring in their feedback.

There are just about 9000 bugs in the kernel bugtracker and about 150000 
bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of 
applications, but still I think the number of bug reports in the kernel 
bugtracker is ridicolously low. And I think thats because many users 
don't bother to report bugs upstream for the Linux kernel, not because 
that those bugs aren't there.

I hope that the ck mailing list community will continue to be active and 
possibly try to get swap prefetch and some other goodies of the ck 
patchset into mainline. And I think it would also be a good idea for ck 
mailing list community to report desktop related issues in the kernel 
bugtracker. I think I will take the courage next time I find anything, 
and report it straight there.

Maybe some talented developer will take up on the ck patchset and maybe 
once in a while he will find a friendlier environment to merge in parts 
of the ck patchset that should have gone mainline years ago. 

Maybe at least that is learned out of what happened here. I do think that 
a *friendly* tone matters and makes a difference. Being friendly and 
honestly saying the own oppinion on technical matters simply do not have 
to contradict themselves. Still I got the impression that some do 
think "Either I say it harsh and true or I be friendly and lie what 
goes".

[1] http://apcmag.com/6735/interview_con_kolivas

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Reporting bugs (was Re: [ck] Re: Linus 2.6.23-rc1)

[Stefan Richter]

Martin Steigerwald wrote:
> There are just about 9000 bugs in the kernel bugtracker and about 150000 
> bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of 
> applications, but still I think the number of bug reports in the kernel 
> bugtracker is ridicolously low. And I think thats because many users 
> don't bother to report bugs upstream for the Linux kernel, not because 
> that those bugs aren't there.
> 
> I hope that the ck mailing list community will continue to be active and 
> possibly try to get swap prefetch and some other goodies of the ck 
> patchset into mainline. And I think it would also be a good idea for ck 
> mailing list community to report desktop related issues in the kernel 
> bugtracker. I think I will take the courage next time I find anything, 
> and report it straight there.

A word of caution about bugzilla.kernel.org, to those who don't know
already:  By far not all maintainers and developers use bugzilla.
I don't know for which subsystems it makes sense to file a report in
bugzilla.  I think your best bet is to report at the mailinglists
listed in linux/MAINTAINERS.
-- 
Stefan Richter
-=====-=-=== -=== ===--
http://arcgraph.de/sr/

Re: Reporting bugs (was Re: [ck] Re: Linus 2.6.23-rc1)

[Michal Piotrowski]

Hi,

On 28/07/07, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Martin Steigerwald wrote:
> > There are just about 9000 bugs in the kernel bugtracker and about 150000
> > bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of
> > applications, but still I think the number of bug reports in the kernel
> > bugtracker is ridicolously low. And I think thats because many users
> > don't bother to report bugs upstream for the Linux kernel, not because
> > that those bugs aren't there.
> >
> > I hope that the ck mailing list community will continue to be active and
> > possibly try to get swap prefetch and some other goodies of the ck
> > patchset into mainline. And I think it would also be a good idea for ck
> > mailing list community to report desktop related issues in the kernel
> > bugtracker. I think I will take the courage next time I find anything,
> > and report it straight there.
>
> A word of caution about bugzilla.kernel.org, to those who don't know
> already:  By far not all maintainers and developers use bugzilla.
> I don't know for which subsystems it makes sense to file a report in
> bugzilla.  I think your best bet is to report at the mailinglists
> listed in linux/MAINTAINERS.

Please CC all bug reports to LKML. I've got a large mailbox, but I
don't want to subscribe all linux-* mailing lists :).

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: Linus 2.6.23-rc1

[Kasper Sandberg]

On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote:
> 
> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
> >
> > Im still not so keen about this, Ingo never did get CFS to match SD in
> > smoothness for 3d applications, where my test subjects are quake(s),
> > world of warcraft via wine, unreal tournament 2004. And this is despite
> > many patches he sent me to try and tweak it.
> 
> You realize that different people get different behaviour, don't you? 
> Maybe not.

Sure.

> 
> People who think SD was "perfect" were simply ignoring reality. Sadly, 
> that seemed to include Con too, which was one of the main reasons that I 
> never ended entertaining the notion of merging SD for very long at all: 
> Con ended up arguing against people who reported problems, rather than 
> trying to work with them.

Im not saying its perfect, not at all, neither am i saying CFS is bad,
surely CFS is much better than the old one, and i agree with what that
university test you mentioned on kerneltrap says, that CFS and SD is
basically impossible to feel difference in, EXCEPT for 3d under load,
where CFS simply can not compete with SD, theres no but, this is how it
has acted on every system ive tested, and YES, others reported it too,
whether you choose to see it or not. and others people who run games on
linux tells me the exact same thing, and i have had quite a few people
try this.

> 
> Andrew also reported an oops in the scheduler when SD was merged into -mm, 
> so there were other issues.

And whats the point here? If you are trying to pull the old "Con just
runs away", forget it, its a certainty that he would have put the
required time into fixing whatever issues arise.

> 
> > As far as im concerned, i may be forced to unofficially maintain SD for 
> > my own systems(allthough lots in the gaming community is bound to be 
> > interrested, as it does make games lots better)
> 
> You know what? You can do whatever you want to. That's kind of the point 
> of open source. Keep people honest by having alternatives.

True that

> 
> But the the thing is, if you want to do a good job of doing that, here's a 
> big hint: instead of keeping to your isolated world, instead of just 
> talking about your own machine and ignoring other peoples machines and 
First off, i've personally run tests on many more machines than my own,
i've had lots of people try on their machines, and i've seen totally
unrelated posts to lkml, plus i've seen the experiences people are
writing about on IRC. Frankly, im not just thinking of myself.

> issues and instead of just denying that problems may exist, and instead of 
> attacking people who report problems, how about working with them?

As i recall, there was only 1 persons reports that were attacked, and
that was because the person repeatedly reported the EXPECTED behavior as
broken, simply because it was FAIRLY allocating the cpu time, and this
did not meet with the dudes expectations. And it was after multiple
mails he was "attacked"

> 
> That was where the SD patches fell down. They didn't have a maintainer 
> that I could trust to actually care about any other issues than his own.

You may not have been able to trust Con, but thats because you havent
taken the time to actually really see whats been going on, if you just
read the threads for SD you'd realize that he was more than willing to
maintain it, after all, why do you think he wrote and submitted it? you
think he just wrote it to piss you off by having it merged and leave?

> 
> So here's a hint: if you think that your particular graphics card setup is 
> the only one that matters, it's not going to be very interesting for 
> anybody else.

as explained earlier, its not just my particular setup, but actually
that of alot of people, with lots of different hardware.

>  
> 
> [ I realize that this comes as a shock to some of the SD people, but I'm 
>   told that there was a university group that did some double-blind 
>   testing of the different schedulers - old, SD and CFS - and that 
>   everybody agreed that both SD and CFS were better than the old, but that 
>   there was no significant difference between SD and CFS. You can try 
>   asking Thomas Gleixner for more details. ]
> 
> I'm happy that SD was perfect for you. It wasn't for others, and it had 
> nobody who was even interested in trying to solve those issues. 
> 
> As a long-term maintainer, trust me, I know what matters. And a person who 
> can actually be bothered to follow up on problem reports is a *hell* of a 
> lot more important than one who just argues with reporters.

Okay, i wasnt going to ask, but ill do it anyway, did you even read the
threads about SD? Con was extremely polite to everyone, and he did work
with a multitude of people, you seem to be totally deadlocked into the
ONE incident with a person that was unhappy with SD, simply for being a
fair scheduler.

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

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>
> First off, i've personally run tests on many more machines than my own,
> i've had lots of people try on their machines, and i've seen totally
> unrelated posts to lkml, plus i've seen the experiences people are
> writing about on IRC. Frankly, im not just thinking of myself.

Ok, good. Has anybody tried to figure out why 3D games seem to be such a 
special case? 

I know Ingo looked at it, and seemed to think that he found and fixed 
something. But it sounds like it's worth a lot more discussion.

> Okay, i wasnt going to ask, but ill do it anyway, did you even read the
> threads about SD?

I don't _ever_ go on specialty mailing lists. I don't read -mm, and I 
don't read the -fs mailing lists. I don't think they are interesting. 

And I tried to explain why: people who concentrate on one thing tend to 
become this self-selecting group that never looks at anything else, and 
then rejects outside input from people who hadn't become part of the "mind 
meld". 

That's what I think I saw - I saw the reactions from where external people 
were talking and cc'ing me.

And yes, it's quite possible that I also got a very one-sided picture of 
it. I'm not disputing that. Con was also ill for a rather critical period, 
which was certainly not helping it all.

> Con was extremely polite to everyone, and he did work
> with a multitude of people, you seem to be totally deadlocked into the
> ONE incident with a person that was unhappy with SD, simply for being a
> fair scheduler.

Hey, maybe that one incident just ended up being a rather big portion of 
what I saw. Too bad. That said, the end result (Con's public gripes about 
other kernel developers) mostly reinforced my opinion that I did the right 
choice.

But maybe you can show a better side of it all. I don't think _any_ 
scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends 
up being not "one or the other", but "somewhere in between".

It's not like we've come to the end of the road: the baseline has just 
improved. If you guys can show that SD actually is better at some loads, 
without penalizing others, we can (and will) revisit this issue.

So what you should take away from this is that: from what I saw over the 
last couple of months, it really wasn't much of a decision. The difference 
in how Ingo and Con reacted to peoples reports was pretty stark. And no, I 
haven't followed the ck mailing list, and so yes, I obviously did get just 
a part of the picture, but the part I got was pretty damn unambiguous.

But at the same time, no technical decision is ever written in stone. It's 
all a balancing act. I've replaced the scheduler before, I'm 100% sure 
we'll replace it again. Schedulers are actually not at all that important 
in the end: they are a very very small detail in the kernel.

				Linus

Re: Linus 2.6.23-rc1

[Kasper Sandberg]

On Sat, 2007-07-28 at 10:50 -0700, Linus Torvalds wrote:
> 
> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
> >
> > First off, i've personally run tests on many more machines than my own,
> > i've had lots of people try on their machines, and i've seen totally
> > unrelated posts to lkml, plus i've seen the experiences people are
> > writing about on IRC. Frankly, im not just thinking of myself.
> 
> Ok, good. Has anybody tried to figure out why 3D games seem to be such a 
> special case? 
> 
> I know Ingo looked at it, and seemed to think that he found and fixed 
> something. But it sounds like it's worth a lot more discussion.
> 

Yes, but the various patches i've recieved seems to not solve it, it
simply changed the load at which CFS seemed to perform well.

On irc there has been wild speculation as to whether its the
sched_yield() stuff in most 3d drivers, but my tests with stubbing it
out, and altering behavior has not changed anything.

> > Okay, i wasnt going to ask, but ill do it anyway, did you even read the
> > threads about SD?
> 
> I don't _ever_ go on specialty mailing lists. I don't read -mm, and I 
> don't read the -fs mailing lists. I don't think they are interesting. 
> 
> And I tried to explain why: people who concentrate on one thing tend to 
> become this self-selecting group that never looks at anything else, and 
> then rejects outside input from people who hadn't become part of the "mind 
> meld". 
> 
> That's what I think I saw - I saw the reactions from where external people 
> were talking and cc'ing me.
> 
> And yes, it's quite possible that I also got a very one-sided picture of 
> it. I'm not disputing that. Con was also ill for a rather critical period, 
> which was certainly not helping it all.
> 
> > Con was extremely polite to everyone, and he did work
> > with a multitude of people, you seem to be totally deadlocked into the
> > ONE incident with a person that was unhappy with SD, simply for being a
> > fair scheduler.
> 
> Hey, maybe that one incident just ended up being a rather big portion of 
> what I saw. Too bad. That said, the end result (Con's public gripes about 
> other kernel developers) mostly reinforced my opinion that I did the right 
> choice.
> 
> But maybe you can show a better side of it all. I don't think _any_ 
> scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends 
> up being not "one or the other", but "somewhere in between".
> 
> It's not like we've come to the end of the road: the baseline has just 
> improved. If you guys can show that SD actually is better at some loads, 
> without penalizing others, we can (and will) revisit this issue.

well, as far as my tests show, the only real difference between SD and
CFS in terms of performance, is 3d, where both will deliver basically
the same FPS in a given application, SD does it smooth, which is the
best way to explain it, what happens with CFS, as i experience it, is
that it seems to burstly allocate ressources.

> 
> So what you should take away from this is that: from what I saw over the 
> last couple of months, it really wasn't much of a decision. The difference 
> in how Ingo and Con reacted to peoples reports was pretty stark. And no, I 
> haven't followed the ck mailing list, and so yes, I obviously did get just 
> a part of the picture, but the part I got was pretty damn unambiguous.

I really think you should try read the SD and RSDL threads on lkml
again, the only place where con havent been extremely fourthcoming was
deep in the thread where Mike was unhappy with SD not giving X more
prioity than fairness dictates..

> 
> But at the same time, no technical decision is ever written in stone. It's 
> all a balancing act. I've replaced the scheduler before, I'm 100% sure 
> we'll replace it again. Schedulers are actually not at all that important 
> in the end: they are a very very small detail in the kernel.
> 
> 				Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linus 2.6.23-rc1

[Jan Engelhardt]

On Jul 28 2007 10:50, Linus Torvalds wrote:
>On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>>
>> First off, i've personally run tests on many more machines than my own,
>> i've had lots of people try on their machines, and i've seen totally
>> unrelated posts to lkml, plus i've seen the experiences people are
>> writing about on IRC. Frankly, im not just thinking of myself.
>
>Ok, good. Has anybody tried to figure out why 3D games seem to be such a 
>special case? 

Is it specific to 3D? I would not think so. dosbox, bochs should have
the same issue. Games with "a lot of motion" usually implement their event
handling and screen drawing in a busy loop to get the maximum possible
frame rate.

Usually, only the GL thread would need to run at full power, and reducing the
input subsystem to a simple event-based loop (for example reading a pipe in
blocking mode). This could IMO makes games a bit more responsive.

However, most games combine the input subsystem and graphics output in one
thread. Due to the way CFS works, it may mean that processes get scheduled
too fair, though I'd suspect that a GL busy loop has no interactivity bonus at
all anyway in the old scheduler or SD.




I/O is also something that can hurt games in their framerate and/or handling
(something the user cares most about). Since I have not tried 2.6.23-rc yet, I
can only speak for the old scheduler. I have always turned cron off so that
updatedb does not run, because it makes games sluggish for some reason,
even though updatedb (or subordinate processes) don't take a lot of CPU time
according to `top`. What's more, running BOINC in the background (nice 20)
while running unreal (nice 0), everything is ok.
(But not if BOINC is at nice 0).

Time to investigate...



	Jan
-- 

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> 
> Time to investigate...

Well, one thing that would be worth doing is to simply create a trace of 
time-slices for both schedulers.

It could easily be some hacky thing that just saves the process name and 
TSC at each scheduling event in some fairly small fixed-sized per-CPU 
circular buffer, and have a /sys interface that reads it out, and then you 
do

	sleep 60 ; cat /sys/cpubuffer > buffer

and play the game for 60 seconds (so that you get a buffer that represents 
perhaps the last 10 seconds of play).

It could *literally* just be an effect of the time quanta used, and CFS 
just deciding that it's not interactive and giving things too long of a 
CPU slice.

Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to 
tweak, but maybe there's some misfeature there, or maybe the default is 
just bad for games, or whatever.

Ingo: that sysctl_sched_granularity initialization doesn't make sense. You 
talk about it being in units of nanoseconds, but then you do

	2000000000ULL/HZ

which is nonsensical. That value is "2 seconds" (not 2ms like the comment 
says) in nanoseconds, but then divided by HZ, so what's the meaning of 
that HZ thing? Nothing in the scheduler should care about jiffies, why is 
that related to HZ? All the scheduler clocks are in ns.

			Linus

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Linus Torvalds wrote:
> 
> Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to 
> tweak, but maybe there's some misfeature there, or maybe the default is 
> just bad for games, or whatever.
> 
> Ingo: that sysctl_sched_granularity initialization doesn't make sense. You 
> talk about it being in units of nanoseconds, but then you do
> 
> 	2000000000ULL/HZ
> 
> which is nonsensical.

Btw, people who actually have 3D games installed (I have exactly one: 
ppracer, and I can't really say that I care about how it feels), if you 
don't have CONFIG_HZ=1000, this really is worth testing.

I think Ingo probably ran with CONFIG_NO_HZ and HZ_1000, but the default 
timer tick is actually 250Hz, which makes all the default scheduler values 
come out four times bigger than they are documented/supposed to be.

On SMP, that scheduler granularity then gets doubled once more if you have 
two CPU's, so rather than 2ms by default, it ends up being 16ns (and the 
time slices themselves end up being bigger than that). 

So doing some testing with a simple

	echo 2000000 > /proc/sys/kernel/sched_granularity_ns
	echo 1000000 > /proc/sys/kernel/sched_batch_wakeup_granularity_ns
	echo 8000000 > /proc/sys/kernel/sched_runtime_limit_ns

might be worth doing (and if you vary numbers to see if it matters, 
please do let people know!)

		Linus

Re: Linus 2.6.23-rc1

[Jan Engelhardt]

On Jul 28 2007 14:33, Linus Torvalds wrote:
>
>Btw, people who actually have 3D games installed (I have exactly one: 
>ppracer, and I can't really say that I care about how it feels), if you 
>don't have CONFIG_HZ=1000, this really is worth testing.
>
>I think Ingo probably ran with CONFIG_NO_HZ and HZ_1000, but the default 
>timer tick is actually 250Hz, which makes all the default scheduler values 
>come out four times bigger than they are documented/supposed to be.

I generally run with CONFIG_HZ=100, CONFIG_NO_HZ=n, CONFIG_PREEMPT_NONE.



	Jan
-- 

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> 
> I generally run with CONFIG_HZ=100, CONFIG_NO_HZ=n, CONFIG_PREEMPT_NONE.

Ok, that's HZ=100 is likely the worst case, as it effectively multiples 
all the scheduler latencies by 10 (rather than by 4, which is what the 
default 250Hz does).

That said, I think most testing showed that the CFS scheduler tunables 
didn't have a huge amount of impact on how things felt, so that 
factor-of-ten might not even matter that much. The 3D game issues may well 
be totally elsewhere.

But it's certainly worth looking at.

		Linus

Re: Linus 2.6.23-rc1

[Jan Engelhardt]

On Jul 28 2007 12:34, Linus Torvalds wrote:
>On Sat, 28 Jul 2007, Jan Engelhardt wrote:
>> 
>> Time to investigate...

Well it really is different.

Simple test:
- run Unreal Tournament 99 (nice 0, it gets 98%,99% CPU most of the time)
- in a shell, `renice 20 $$; while :; do date; done;`

The shell only produces one or two outputs per second.
This seems different from the old-2.6 behavior, where a nice-20
process seemed to get a bit more share. (Due to interactivity bonus)


Does anyone have a cpu hog test program that spreads its cpu time
over the second rather than doing 300 ms wake and 700 ms sleep cycles
after another?

>Well, one thing that would be worth doing is to simply create a trace of 
>time-slices for both schedulers.
>
>It could easily be some hacky thing that just saves the process name and 
>TSC at each scheduling event in some fairly small fixed-sized per-CPU 
>circular buffer, and have a /sys interface that reads it out, and then you 
>do
>
>	sleep 60 ; cat /sys/cpubuffer > buffer
>
>and play the game for 60 seconds (so that you get a buffer that represents 
>perhaps the last 10 seconds of play).

Send me patches, I run the test.

>It could *literally* just be an effect of the time quanta used, and CFS 
>just deciding that it's not interactive and giving things too long of a 
>CPU slice.
>
>Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to 
>tweak, but maybe there's some misfeature there, or maybe the default is 
>just bad for games, or whatever.
>
>Ingo: that sysctl_sched_granularity initialization doesn't make sense. You 
>talk about it being in units of nanoseconds, but then you do
>
>	2000000000ULL/HZ
>
>which is nonsensical. That value is "2 seconds" (not 2ms like the comment 
>says) in nanoseconds, but then divided by HZ, so what's the meaning of 
>that HZ thing? Nothing in the scheduler should care about jiffies, why is 
>that related to HZ? All the scheduler clocks are in ns.
>
>			Linus
>

	Jan
-- 

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

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

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
> > Im still not so keen about this, Ingo never did get CFS to match SD
> > in smoothness for 3d applications, where my test subjects are
> > quake(s), world of warcraft via wine, unreal tournament 2004. And
> > this is despite many patches he sent me to try and tweak it.

[...]

> I'm happy that SD was perfect for you. It wasn't for others, and it had
> nobody who was even interested in trying to solve those issues.

Linus, I seen somethimg *completely* different on the CK mailinglist. Con 
Koliva worked up to his limits and likely beyond them to fix any and all 
issues reported. Heck, he maintained that thing out of the kernel tree 
for a long time and the version number 1.0 does not come from nothing, it 
has gone through at least 50 iterations.

The only thing I know of where Con did not want to "fix" a problem, was 
with renicing X, cause he didn't want to introduce a special case in the 
scheduler, where a simple nice would do the trick. That said I never saw 
serious problems with X unreniced at all.

So I think your statements here are simply not accurate and also not fair, 
cause I have the impression that you did not look carefully before 
writing them.

You speak about working together, but now I ask you: Did you ever have a 
personal word with Con, did you ever tell him that you don't trust that 
he can maintain the SD scheduler when its mainline? Did you ever outspoke 
your concerns to *him*?

Granted, from a health point of view and maybe also from looking at how 
much time a maintainer will be able to spend more time on the scheduler 
Ingo *may* can do more than Con - if he doesn't do too much else;-). But 
looking at personal committment actually I saw no difference between Con 
and Ingo.

So while it may be good that CFS went in from that point of view, the way 
the decision was made was very suitable to piss off a very talented 
developer.

Anyway, the decision is done, Con resigned already, he gave up on it. And 
actually when I read your mail I can understand why he did so[1]. Sure, 
he is involved as well and I think he felt hurt on some things that in my 
perception were meant neutral or even supporting and postive, but still I 
disagree a lot on the tone in LKML and understand exactly why Linux 
users, Linux desktop users away from it as much as they can. Actually I 
do not get that as you state in one of your latest interviews that you 
are actually very interested into the desktop, cause its a very suitable 
kernel test case[2].

Well I for sure will patch whatever into my kernels that I think should be 
in there for me to have a *pleasant* desktop experience, including, but 
not limited to, TuxOnIce ;-). Oh, but that might possibly not be mainted 
nicely enough as well then. (Yes, here is sarcastic irony, lots of it. So 
no offence intended, Nigel;-)


[1] http://apcmag.com/6735/interview_con_kolivas
[2] http://www.oneopensource.it/interview-linus-torvalds/


Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Dirk Schoebel]

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

Up till now i haven't read the interview with Linus.

> [2] http://www.oneopensource.it/interview-linus-torvalds/
>

It is interesting, he mentiones a lesson to learn from Microsoft:
"'Well, historically, the most important lesson from Microsoft - and one they 
themselves seem to have forgotten - is simply 'Give your customers what they 
want'."
But as i see all the discussion here that's what's _not_ being honored. People 
request swap prefetch, it wouldn't be hard to give it to them but they 
probably won't get it (or it takes a 5 days, 200+ messages discussion(in the 
ck list alone were already 190 messages posted about this)).
Give the people plugshed so everyone can happily be using SD instead of CFS -  
no way!
There sure are more examples to be given.

Dirk.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Michael Chang]

On 7/27/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Con ended up arguing against people who reported problems, rather than
> trying to work with them.

I do recall there is one issue on which Con wouldn't budge -- anything
that involved boosting certain kinds of processes in the kernel. He
said that it would defeat the whole point of the way he had designed
it, and that nicing could work just as well. Perhaps there could have
been a better way of handling that issue, such as adding (yet another)
kernel compilation configuration option for this code (since Con
didn't believe it would help all users).

> Andrew also reported an oops in the scheduler when SD was merged into -mm,
> so there were other issues.

I don't know how you can blame Con for not finding a PPC oops before
SD was merged into -mm, considering he seemed to be coding solely on
an x86-based architecture. Of course, you could say that his design
should have factored in all the architectures and such, but even the
best design can fall apart if it doesn't get tested somewhere. Again,
this is probably a subjective case in that Con might have pushed SD to
-mm rather early; but considering the readership of his -ck list, I
don't think it would have been tested on anything other than X86 until
it went into -mm because I've ever seen anyone on -ck report "it works
on <something other than x86/x86-64/IA64>". I don't know what made it
on to other lists, but Con tried his best to fix this oops, and unless
it was done privately, this oops was never re-reported. (Now, if SD
was _STILL_ causing this oops on PPC, I can see how this might be a
concern.)

> > As far as im concerned, i may be forced to unofficially maintain SD for
> > my own systems(allthough lots in the gaming community is bound to be
> > interrested, as it does make games lots better)
>
> You know what? You can do whatever you want to. That's kind of the point
> of open source. Keep people honest by having alternatives.
>
> But the the thing is, if you want to do a good job of doing that, here's a
> big hint: instead of keeping to your isolated world, instead of just
> talking about your own machine and ignoring other peoples machines and
> issues and instead of just denying that problems may exist, and instead of
> attacking people who report problems, how about working with them?
>
> That was where the SD patches fell down. They didn't have a maintainer
> that I could trust to actually care about any other issues than his own.

So if we found a better maintainer who would commit to maintaining the
SD patches, would you still be willing to consider merging them? Is
this what you're saying?

> I'm happy that SD was perfect for you. It wasn't for others, and it had
> nobody who was even interested in trying to solve those issues.

-- 
Michael Chang

Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Michael Chang wrote:
> 
> I do recall there is one issue on which Con wouldn't budge -- anything
> that involved boosting certain kinds of processes in the kernel.

I did that myself, so that's a non-issue.

No. The complaints were about the CK scheduler not being as responsive 
under load as even the _old_ scheduler was. I don't know why people ignore 
this fact. It was a long thread back in March or April, and I'm pretty 
sure the CK mailing list was cc'd.

Sure, most people don't actually have load-averages above ten etc, but 
it's important to do those well _too_. 

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[jos poortvliet]

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

Op Saturday 28 July 2007, schreef Linus Torvalds:
> On Sat, 28 Jul 2007, Michael Chang wrote:
> > I do recall there is one issue on which Con wouldn't budge -- anything
> > that involved boosting certain kinds of processes in the kernel.
>
> I did that myself, so that's a non-issue.
>
> No. The complaints were about the CK scheduler not being as responsive
> under load as even the _old_ scheduler was. I don't know why people ignore
> this fact. It was a long thread back in March or April, and I'm pretty
> sure the CK mailing list was cc'd.

Of course it wasn't. The speed of tasks slows proportionally with the amount 
of system usage. That's the whole point, and CFS can't fix that either, can 
it?

> Sure, most people don't actually have load-averages above ten etc, but
> it's important to do those well _too_.
>
> 			Linus

<sarcasm>
http://osnews.com/permalink.php?news_id=18350&comment_id=259044

Now I wonder. Apparently, one person complaining about SD was reason to keep 
it out http://osnews.com/permalink.php?news_id=18350&comment_id=258997

Will this first post stop CFS from entering the kernel?
</sarcasm>


Now I'll try to be a bit more constructive. I hope your benevolent 
dictatorship allows self reflection.

Sure, the difference in behaviour (not in code) between SD and CFS is small, 
and for me it doesn't matter. I'm fine with CFS in the kernel, it's a huge 
improvement over the previous one. But why, while there was a seemingly good 
alternative, did THAT one stay in that long? And this argument goes for more 
code 'out there', btw.
 
 Some things get into the kernel, other don't. Some get in too soon, others 
too late. Sure. But shouldn't we try to improve this process, instead of 
saying 'it is what it is, get over it'?
 
 For me, that's the purpose of this whole discussion. We're losing valuable 
code and contributors, yet at the same time code which isn't mature yet 
enters the kernel. Acknowledging there is a problem is the first step in 
solving it.

 Of course, I don't have answers - but I do feel strongly that you think there 
is no issue. Is there, or isn't there? And if there is, what do you plan to 
do about it?



Your influence on the behaviour of the people around you, your 'lieutenants', 
is huge. Larger than you might think. And in many cases, ppl following 
someone behave more extreme. That's a big reason why the LKML isn't very 
polite nor inviting (mind you, I don't think that's necessarily a bad thing, 
that's up to you to decide).

You might want to think about ways to improve the whole process. Again, I'm no 
Linus, it's your call. And you can make a big difference, I'm sure.


Greetings,

Jos

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, jos poortvliet wrote:
> 
> <sarcasm>

Actually, the tag you were looking for was "<clueless>"

> http://osnews.com/permalink.php?news_id=18350&comment_id=259044
> 
> Now I wonder. Apparently, one person complaining about SD was reason to keep 
> it out http://osnews.com/permalink.php?news_id=18350&comment_id=258997
> 
> Will this first post stop CFS from entering the kernel?

You seem to be not understanding the argument.

It wasn't about "one person complaining". Of *course* people will 
complain. That always happens, and sometimes with totally bogus complaints 
(the most common being "I'm not used to it").

The problem was the reaction to complaints. 

Ingo got lots of complaints too. He was very responsive to them (which is 
not something surprising - he's been doing this a long time), and while 
some of the tangents he went off on were definitely bogus (the whole 
renicing thing), they were still useful as part of the discussion.

And Ingo got other - totally unrelated - developers involved too, ie the 
group fairness logic came from Vatsa. And he ended up supporting not just 
scheduler people, but also talking to the block layer people ahout the 
scheduler timer usage as a fast clock for block requests etc.

And you have to realize that to me, as the top-level maintainer and one 
who seldom actually does big coding things, but just ends up making sure 
that people work with others, and fix the problems that crop up, *that* 
kind of behaviour is much much MUCH more important than the code itself.

Can you see that?

Can you see how big of a difference those whole approaches make? 

> Now I'll try to be a bit more constructive. I hope your benevolent 
> dictatorship allows self reflection.

Nobody is very good at self-reflection, I'm afraid. 

> Sure, the difference in behaviour (not in code) between SD and CFS is small, 
> and for me it doesn't matter. I'm fine with CFS in the kernel, it's a huge 
> improvement over the previous one. But why, while there was a seemingly good 
> alternative, did THAT one stay in that long? And this argument goes for more 
> code 'out there', btw.

Actually, nobody pushed SD to me, and neither Con nor anybody else tried 
to get me to merge it until some time in March of this year, I think.

Do you think I go trolling for code to merge? No. I actually _require_ 
that people send it to me, and that I also get the feeling that people are 
asking for it! 

In other words, my job is not to "merge code" (even though I sometimes 
describe it that way), my job is actually largely to "say no". You 
shouldn't see me as the person who goes out and tries to get everything 
together - quite the reverse. My job is to say "too late for the merge 
window", or "too experimental", or "you need to show numbers" or "are 
there going to be any _users_ for this"?

>  Some things get into the kernel, other don't. Some get in too soon, others 
> too late. Sure. But shouldn't we try to improve this process, instead of 
> saying 'it is what it is, get over it'?

Umm. The absolute *last* thing we want to do is to merge earlier. In fact, 
one of our biggest problems is that people send half-cooked stuff to me 
(and even more so, to Andrew). 

So in this case, if you've been on the CK mailing list, ask yourself: why 
wasn't parts of it pushed up to the standard kernel? Asking "why didn't 
Linus take it earlier" is exactly the wrong thing to do, since nobody even 
_asked_ me to. I never _ever_ got a patch saying "please merge this".

Seriously.

(Btw, on that note: please don't send me patches saying "please merge 
this". I want more than just that. I want an explanation, and I want it to 
be in many small pieces, and I want to feel like it got tested and is 
likely to be an obvious improvement).

So now look at what happened to CFS:

 - Ingo pushed it, and has been a maintainer of the area and shown himself 
   over years to be able to work with others and react to reports of 
   problems.

 - It was fairly obviously an improvement over the previous status quo
   (although I expect that there will be regressions - almost nothing is 
   ever a _pure_ improvement, if it's in any way non-trivial)

 - Even so, I asked for (and got) a series of independent patches.

Compare this to SD for a while. Ponder.

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[jos poortvliet]

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

Op Saturday 28 July 2007, schreef Linus Torvalds:
<snip stuff i generally sagree with>
>
> Compare this to SD for a while. Ponder.
>
> 			Linus

Your point here seems to be: this is how it went, and it was right. Ok, got 
that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder 
how many did leave without this splash. How many didn't even get involved at 
all??? Did THAT have to happen? I don't blame you for it - the point is that 
somewhere in the process a valuable kernel hacker went away. How and why? And 
is it due to a deeper problem?



-- 
Disclaimer:

Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. 
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat 
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. 
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

   A: Because it destroys the flow of the conversation
   Q: Why is top-posting bad?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Bill Huey]

On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote:
> Your point here seems to be: this is how it went, and it was right. Ok, got 
> that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder 
> how many did leave without this splash. How many didn't even get involved at 
> all??? Did THAT have to happen? I don't blame you for it - the point is that 
> somewhere in the process a valuable kernel hacker went away. How and why? And 
> is it due to a deeper problem?

Absolutely, the current Linux community hasn't realized how large the
community has gotten and the internal processes for dealing with new
developers, that aren't at companies like SuSE or RedHat, haven't been
extended to deal with it yet. It comes off as elitism which it partially
is.

Nobody tries to facilitate or understand ideas in the larger community
which locks folks like Con out that try to do provocative things outside
of the normal technical development mindset. He was punished for doing
so and is a huge failure in this community.

Con basically got caught in a scheduler philosophical argument of whether
to push a policy into userspace or to nice a process instead because
of how crappy X is. This is an open argument on how to solve, but it
should not have resulted in really one scheduler over the other. Both
where capable but one is locked out now because of the choices of
current high level kernel developers in Linux.

There are a lot good kernel folks in many different communities that
look at something like this and would be turned off to participating
in Linux development. And I have a good record of doing rather
interesting stuff in kernel.

bill

Re: [ck] Re: Linus 2.6.23-rc1

[Diego Calleja]

El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) <billh@gnuppy.monkey.org> escribió:

> of how crappy X is. This is an open argument on how to solve, but it
> should not have resulted in really one scheduler over the other. Both

So your argument is that SD shouldn't have been merged either, because it
would have resulted in one scheduler over the other?

> where capable but one is locked out now because of the choices of
> current high level kernel developers in Linux.

Well, there are two schedulers...it's obvious that "high level kernel
developers" needed to chose one.

The main problem is clearly that no scheduler was clearly better than the
other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both
of them were good enought, but only one of them could be merged. The
difference is that EVMS developers didn't get that annoyed, and not only
they didn't quit but they continued developing their userspace tools to
make it work with the solution included in the kernel
(http://lwn.net/Articles/14714/)

Re: [ck] Re: Linus 2.6.23-rc1

[Bill Huey]

On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote:
> So your argument is that SD shouldn't have been merged either, because it
> would have resulted in one scheduler over the other?

My argument is that schedule development is open ended. Although having
a central scheduler to hack is a a good thing, it shouldn't lock out or
supress development from other groups that might be trying to solve the
problem in unique ways.

This can be accomplished in a couple of ways:

1) scheduler modularity

Clearly Con is highly qualified to experiement with scheduler code and
this should be technically facilitate by some means if not a maintainer.
He's only a part time maintainer and nobody helped him with this stuff
nor did they try to understand what his scheduler was trying to do other
than Tong Li.

2) better code modularity

Now, cleaner code would help with this a lot. If that was in place, we
might not need (1) and pluggable scheduler. It would limit the amount
of refactoring for folks so that their code can drop in easier. There's
a significant amount of churn that it locks out developers by default
since they have to constantly clean up the code in question while another
developer can commit without consideration to how it effects others.
That's their right as a maintainer, but also as maintainer, they should
give proper amount of consideration to how others might intend to extend
the code so that development remains "inclusive".

This notion of "open source, open development" is false when working
under those circumstances.

> > where capable but one is locked out now because of the choices of
> > current high level kernel developers in Linux.
> 
> Well, there are two schedulers...it's obvious that "high level kernel
> developers" needed to chose one.

I think that's kind of a bogus assumption from the very get go. Scheduling
in Linux is one of the most unevolved systems in the kernel that still
could go through a large transformation and get big gains like what
we've had over the last few months. This evident with both schedulers,
both do well and it's a good thing overall the CFS is going in.

Now, the way it happened is completely screwed up in so many ways that I
don't see how folks can miss it. This is not just Ingo versus Con, this
is the current Linux community and how it makes decision from the top down
and the current cultural attitude towards developers doing things that
are:

1) architecturally significant

which they will get flamed to death by the establish Linux kernel culture
before they can get any users to report bugs after their posting on lkml.

2) conceptual different

which is subject to the reasons above, but also get flamed to death unless
it comes from folks internal to the Linux development processes.

When groups get to a certain size like it has, there needs to be a
revision of development processes so that they can scale and be "inclusive"
to the overall spirit the Linux development process. When that breaks down,
we get situations like what we have with Con leaving development. Other
developers like me get turned off to the situation, also feel the same as
Con and stop Linux development. That's my current status as well.

> The main problem is clearly that no scheduler was clearly better than the
> other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both
> of them were good enought, but only one of them could be merged. The
> difference is that EVMS developers didn't get that annoyed, and not only
> they didn't quit but they continued developing their userspace tools to
> make it work with the solution included in the kernel

That's a good point to have folks not go down that particular path. But
Con was kind of put down during the arguments with Ingo about his
assumptions of the problems and then was personally crapped on by having
his own idea under go a a complete reversal in opinion by Ingo, with
Ingo then doing this own version of Con's work displacing him

How would you feel in that situation ? I'd be pretty damn pissed.

[For the record Peter Zijlstra did the same thing to me which is annoying,
but since he's my buddy doesn't get as rude as the above situation, included
me in every private mail about his working so that I don't feel like RH
is paying him to undermine my brilliance, it's ok :)]

bill

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Bill Huey wrote:
> 
> My argument is that schedule development is open ended. Although having
> a central scheduler to hack is a a good thing, it shouldn't lock out or
> supress development from other groups that might be trying to solve the
> problem in unique ways.

I don't think anything was suppressed here.

You seem to say that more modular code would have helped make for a nicer 
way to do schedulers, but if so, where were those patches to do that? 
Con's patches didn't do that either. They just replaced the code.

In fact, Ingo's patches _do_ add some modularity, and might make it easier 
to replace the scheduler. So it would seem that you would argue for CFS, 
not against it?

> I think that's kind of a bogus assumption from the very get go. Scheduling
> in Linux is one of the most unevolved systems in the kernel that still
> could go through a large transformation and get big gains like what
> we've had over the last few months. This evident with both schedulers,
> both do well and it's a good thing overall the CFS is going in.
> 
> Now, the way it happened is completely screwed up in so many ways that I
> don't see how folks can miss it. This is not just Ingo versus Con, this
> is the current Linux community and how it makes decision from the top down
> and the current cultural attitude towards developers doing things that
> are:

I don't think so.

I think you're barking up the totally wrong tree here.

I think that what happened was very simple: somebody showed that we did 
badly and had benchmarks to show for it, and that in turn resulted in a 
huge spurt of coding from the people involved.

The fact that you think this is "broken" is interesting. I can point to a 
very real example of where this also happened, and where I bet you don't 
think the process was "broken".

Do you remember the mindcraft study?

Exact same thing. Somebody came in, and showed that Linux did really badly 
on some benchmark, and that an alternate approach was much better.

What happened? A huge spurt of development in a pretty short timeframe, 
that totally _obliterated_ the mindcraft results. 

It could have happened independently, but the fact is, it didn't. These 
kinds of events where somebody shows (with real numbers and code) that 
things can be done better really *are* a good way to do development, and 
it's how development generally ends up happening. It's hugely 
motivational, both because competition is motivational in itself, but also 
because somebody shows that things can be done so much better opens 
peoples eyes to it.

And if you think the scheduler situation is different, why? Was it just 
because the mindcraft study compared against Windows NT, not another 
version of Linux patches?

The thing is, development is slow and gradual, but at the same time, it 
happens in spurts (btw, if you have ever studied evolution, you'll find 
the exact same thing: evolution is slow and gradual, but it also happens 
in sudden "spurts" where you have relatively much bigger changes happening 
because you get into a feedback loop).

Another comparison to evolution: most of the competitive pressure actually 
comes from the _same_ species, not from outside. It's not so much rabbits 
competing against foxes (although that happens too), quite a lot of it is 
rabbits competing against other rabbits!

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Bill Huey]

On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote:
> I don't think anything was suppressed here.

I disagree. See below.

> You seem to say that more modular code would have helped make for a nicer 
> way to do schedulers, but if so, where were those patches to do that? 
> Con's patches didn't do that either. They just replaced the code.

They replaced code because he would have liked to have taken scheduler code
in possibly a completely different direction. This is a large conceptual
change from what is currently there. That might also mean how the notion of
bandwidth with regards to core frequency might be expressed in the system
with regards to power saving and other things. Things get dropped often
not because of pure technical reasons but because of person preference
and the lack of willingness to ask where this might take us.

The way that Con works and conceptualizes things is quite a bit different
and more comprehensive in a lot of ways compared to how the regular kernel
community operates. He's strong in this area and weak in general kernel
hackery as a function of time and experience. That doesn't mean that he,
his ideas and his code should be subject to an either/or situation with the
scheduler and other ideas that have been rejected by various folks. He
maintained -ck branch successfully for a long time and is a very capable
developer.

I do acknowledge that having a maintainer that you can trust is more
important, but it should not be exclusionary in this way. I totally
understand his reaction.

> In fact, Ingo's patches _do_ add some modularity, and might make it easier 
> to replace the scheduler. So it would seem that you would argue for CFS, 
> not against it?

It's not the same as sched plugin. Some folks might not like to use the
rbtree that's in place and express things in a completely different
manner. Take for instance, Tong Li's stuff with CFS a bit of a conceptual
mismatch with his attempt at expression rebalancing in terms expiry rounds
yet would be more seamlessly integrated with something like either the old
O(1) scheduler or Con's stuff. It's also the only method posted to lkml
that can deal with fairness across SMP situtations with low error. Yet
what's happening here is that his implementation is being rejected because
of size and complexity because of a data structure conceptual mismatch.

Because of this, his notion of trio as a general method of getting
aggressive group fairness (by far the most complete conceptually on lkml,
over design is a different topic altogether) may never see the light of
day in Linux because of people's collective lack of foresight.

To answer the question that you posed, no. I'm not arguing against it. I'm
in favor of it going into the kernel like any dead line mechanism since
it can be generalized, but the current developement processes in Linux
kernel should not create an either/or situation with the scheduler code.
There has been multipule rejection of ideas with regards to the scheduler
code over the years that could have take things in a very different and
possibly complete kick ass way that was suppress because of the development
attitude of various Linux kernel developers.

It's all of a sudden because of Con's work there's a flurry of development
in this area when this idea is shown to be superior and even then, it's
conceptually incomplete and subject to a lot of arbitrary hacking. This
is very different than Con's development style and mine as well.

This is an area that could have been addressed sooner if the general
community admitted that there was a problem earlier and permitted more
conscious and open change. I've seen changes in this area from Con be
reject time and time again which effect the technical direction he
originally wanted to take this.

Now, Con might have a communication problem here, but nobody asked to
clarify what he might have wanted and why, yet folks were very quick at
dismissing him, nitpick him to death,  even when he explained why he might
have wanted a particular change in the first place. This is the
"facilitation" part that's missing in the current kernel culture.

This is a very important idea as the community grows, because I see folks
that are capable of doing work get discouraged and locked out because of
code maintainability issues and an inability to get folks to move that
direction because of a missing concensus mechanism in the community
other that sucking up to developers.

Con and folks like him should be permitted the opportunity to fail on
their own account. If Linux was truely open, it would have dealt with
issue by now and there wouldn't be so much flammage from the general
community.

> > I think that's kind of a bogus assumption from the very get go. Scheduling
> > in Linux is one of the most unevolved systems in the kernel that still
> > could go through a large transformation and get big gains like what
> > we've had over the last few months. This evident with both schedulers,
> > both do well and it's a good thing overall the CFS is going in.
> > 
> > Now, the way it happened is completely screwed up in so many ways that I
> > don't see how folks can miss it. This is not just Ingo versus Con, this
> > is the current Linux community and how it makes decision from the top down
> > and the current cultural attitude towards developers doing things that
> > are:
> 
> I don't think so.
> 
> I think you're barking up the totally wrong tree here.

Did in any place in your reply did you ask what I meant by this ? Where
somebody like me, Con or Tong (sorry to drag you into this) and others
might like to take this and the -rt ? and other things in the Linux
kernel ? Well, this is a failure of the concensus process in Linux.

> I think that what happened was very simple: somebody showed that we did 
> badly and had benchmarks to show for it, and that in turn resulted in a 
> huge spurt of coding from the people involved.

Or ass kissing from large companies that are afraid to challenge the
Linux kernel norm. And a lot of that stuff is a complete ugly hack. That's
a self fullfulling attribute of the Linux culture that indicative of how
many ass kisser we have in this community that can snow ball any arbitary
phenomenon like CFS.

> The fact that you think this is "broken" is interesting. I can point to a 
> very real example of where this also happened, and where I bet you don't 
> think the process was "broken".

This lack of communication is an indicator of it being broken. Folks not
asking where we could take the Linux kernel, versus hacking it without
background on particular area and listening, is indicative of it. General
lack of direction with development is an indicator of it. Lack of design
discussion and inclusiveness of various designs is an indicator of failure.

> Do you remember the mindcraft study?
> 
> Exact same thing. Somebody came in, and showed that Linux did really badly 
> on some benchmark, and that an alternate approach was much better.
> 
> What happened? A huge spurt of development in a pretty short timeframe, 
> that totally _obliterated_ the mindcraft results. 
> 
> It could have happened independently, but the fact is, it didn't. These 
> kinds of events where somebody shows (with real numbers and code) that 
> things can be done better really *are* a good way to do development, and 
> it's how development generally ends up happening. It's hugely 
> motivational, both because competition is motivational in itself, but also 
> because somebody shows that things can be done so much better opens 
> peoples eyes to it.

Everybody here wants Linux to be better. Everybody, me included. Make no
mistake. But collectively we should not be in a state of "reaction" to
external forces as the only known method of development.

The scheduler could have and still can undertake good solid transformation,
but getting folks to listen is another story which is why Con quit. CFS
basically locks him and his ideas out, not just from a technical stand
point, and sends a personal message that we don't care about him because
we've made zero effort to reach out to him. This is exactly how you laid
it out in previous messages. That's broken. He has his own problems, but
he also produces good work and recognizes the development problems with
the community in his /. article that many folks agree with approach
lkml with bug reports.

It's hack versus design. There needs to be a balance between the two and
a culture to receive both and not create and either/or situation. Con's
method of development should be welcomed.

> And if you think the scheduler situation is different, why? Was it just 
> because the mindcraft study compared against Windows NT, not another 
> version of Linux patches?
> 
> The thing is, development is slow and gradual, but at the same time, it 
> happens in spurts (btw, if you have ever studied evolution, you'll find 
> the exact same thing: evolution is slow and gradual, but it also happens 
> in sudden "spurts" where you have relatively much bigger changes happening 
> because you get into a feedback loop).

This time it was Con being the Mindcraft catalyst. But he's on *our* side
and he got beat down by the Linux kernel community. That's the tragedy here.
He was beaten down by the very people he was trying to help out and
support. It should have been handled better.
 
> Another comparison to evolution: most of the competitive pressure actually 
> comes from the _same_ species, not from outside. It's not so much rabbits 
> competing against foxes (although that happens too), quite a lot of it is 
> rabbits competing against other rabbits!

This is different topic and a distraction from inclusiveness issues. All
groups have a mono-culture. Groups that recognized it and push out of it
make it a win for the entire group and not just for a small set of individuals.

Even as your "arm chair kernel" hacker, I've done things that are out of
the box in Linux and I believe are interesting but never cared for the
politics of mainline.

bill

Re: [ck] Re: Linus 2.6.23-rc1

[Diego Calleja]

El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <billh@gnuppy.monkey.org> escribió:

> The scheduler could have and still can undertake good solid transformation,
> but getting folks to listen is another story which is why Con quit. CFS
> basically locks him and his ideas out, not just from a technical stand

This is just wrong: AFAIK nobody is stopping Con or any other people from
continuing developing SD or any other scheduler, and CFS certainly is subject
to criticism. The idea that Linux can't use other innovative ideas in the scheduler
is only in your mind.


> This time it was Con being the Mindcraft catalyst. But he's on *our* side
> and he got beat down by the Linux kernel community. That's the tragedy here.
> He was beaten down by the very people he was trying to help out and
> support. It should have been handled better.

Get real: I don't the linux development has always been "friendly". The idea
of a "GNU-hippie community" where everybody is good and helps others and
shares their pots is what the Sun bloggers seem to think that opensolaris
should resemble, but it doesn't matches the real world.

Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald]

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

Am Sonntag 29 Juli 2007 schrieb Diego Calleja:

> > This time it was Con being the Mindcraft catalyst. But he's on *our*
> > side and he got beat down by the Linux kernel community. That's the
> > tragedy here. He was beaten down by the very people he was trying to
> > help out and support. It should have been handled better.
>
> Get real: I don't the linux development has always been "friendly". The
> idea of a "GNU-hippie community" where everybody is good and helps
> others and shares their pots is what the Sun bloggers seem to think
> that opensolaris should resemble, but it doesn't matches the real
> world.

Actually I have seen friendly communities around Linux and free software. 
Like the KDE project, the ck patchset mailing list community, the 
TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar 
community, quite some parts of the Debian community just to name a few.

So I know that it can be different. I know that its inaccurate to talk 
about the whole Linux kernel community. I had quite friendly contacts 
with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg 
Kroah-Hartman.

So what would be wrong with looking at how this worked out and why and how 
it would be possible to avoid loosing a talented developer?

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ck] Re: Linus 2.6.23-rc1

[Mike Galbraith]

On Sun, 2007-07-29 at 16:31 +0200, Diego Calleja wrote:
> El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <billh@gnuppy.monkey.org> escribió:
> 
> > The scheduler could have and still can undertake good solid transformation,
> > but getting folks to listen is another story which is why Con quit. CFS
> > basically locks him and his ideas out, not just from a technical stand
> 
> This is just wrong: AFAIK nobody is stopping Con or any other people from
> continuing developing SD or any other scheduler, and CFS certainly is subject
> to criticism. The idea that Linux can't use other innovative ideas in the scheduler
> is only in your mind.

Absolutely.

Con quit for his own reasons.  Given that Con himself has said that CFS
was _not_ why he quite, please discard this... bait.  Anyone who's name
isn't Con Kolivas, who pretends to speak for him is at the very least
overstepping his bounds, and that is being _very_ generous.

	-Mike

Re: [ck] Re: Linus 2.6.23-rc1

[Bill Huey]

On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
> Absolutely.
> 
> Con quit for his own reasons.  Given that Con himself has said that CFS
> was _not_ why he quite, please discard this... bait.  Anyone who's name
> isn't Con Kolivas, who pretends to speak for him is at the very least
> overstepping his bounds, and that is being _very_ generous.

I know Con personally and I completely identify with his circumstance. This
is precisely why he quit the project because of a generally perceived
ignorance and disconnect from end users. Since you side with Ingo on many
issues politically, this response from you is no surprise.

Again, the choices that have been currently made with CFS basically locks
him out of development. If you don't understand that, then you don't
understand the technical issues he's struggled to pursue. He has a large
following which is why this has been a repeated and issue between end users
of his tree and a number of current Linux kernel developers.

bill

Re: [ck] Re: Linus 2.6.23-rc1

[Mike Galbraith]

On Sun, 2007-07-29 at 14:48 -0700, Bill Huey wrote:
> On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
> > Absolutely.
> > 
> > Con quit for his own reasons.  Given that Con himself has said that CFS
> > was _not_ why he quite, please discard this... bait.  Anyone who's name
> > isn't Con Kolivas, who pretends to speak for him is at the very least
> > overstepping his bounds, and that is being _very_ generous.
> 
> I know Con personally and I completely identify with his circumstance. This

You're still not Con, and I still think it's inappropriate for any
person to speak for another unless that person is the designated proxy.

> is precisely why he quit the project because of a generally perceived
> ignorance and disconnect from end users. Since you side with Ingo on many
> issues politically, this response from you is no surprise.

Hm.  I don't recall entering the world of politics.  Where's my cool
lapel button?

	-Mike

Re: [ck] Re: Linus 2.6.23-rc1

[Daniel Phillips]

On Saturday 28 July 2007 14:06, Diego Calleja wrote:
> El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) escribió:
> The main problem is clearly that no scheduler was clearly better than
> the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days -
> both of them were good enought, but only one of them could be merged.
> The difference is that EVMS developers didn't get that annoyed, and
> not only they didn't quit but they continued developing their
> userspace tools to make it work with the solution included in the
> kernel
> > (http://lwn.net/Articles/14714/) 

Not that I want to be in this thread, particularly since it is already 
two weeks stale, but your take on the EVMS story is incorrect.  The 
EVMS developers (that is, Kevin) sent out a nice, conciliatory email, 
the project sputtered on for a while, then basically died.

    http://marc.info/?l=evms-devel&m=118240945708775&w=2

Bill is right.  People who know people are right.  A lot of good talent 
has been lost to Linux over the years because of various, perhaps good 
intentioned, gaffs.  The thing is, if you contribute to a project like 
Linux for fun, when it stops being fun you walk.

Regards,

Daniel

Re: [ck] Re: Linus 2.6.23-rc1

[Alan Cox]

> two weeks stale, but your take on the EVMS story is incorrect.  The 
> EVMS developers (that is, Kevin) sent out a nice, conciliatory email, 
> the project sputtered on for a while, then basically died.

This is perfectly normal. It was outevolved and ran out of people who
cared enough to continue it. Happens all the time. In the proprietary
world its normally one company putting another out of business and lots
of people losing jobs and money so its actually a good deal friendlier
this side of the fence

When you contribute to a big project some of your stuff will get nowhere,
other stuff will eventually get kicked out and replaced. Its part of the
progress of the system.

And yes one day the Linux kernel will probably go the same was as EVMS
when something cooler and neater replaces it.

Re: [ck] Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, jos poortvliet wrote:
>
> Your point here seems to be: this is how it went, and it was right. Ok, got 
> that.

But I wanted to bring out more than what you make sound like "that's what 
happened, deal with it". I tried to explain _why_ the choices that were 
made were in fact made.

And it's a (I think) important thing for people to be aware of. The fact 
is, "personality" and "work with the other developers" is a big issue.

You cannot just go off and do your own thing in your private world, and 
then expect it to be accepted without any discussion or other people 
showing up and doing alternate things. That's _especially_ true in an area 
that has a respected and working maintainer.

>	 Yet, Con walked away (and not just over SD). Seeing Con go, I wonder 
> how many did leave without this splash.

We've had people go with a splash before. Quite frankly, the current 
scheduler situation looks very much like the CML2 situation. Anybody 
remember that? The developer there also got rejected, the improvement was 
made differently (and much more in line with existing practices and 
maintainership), and life went on. Eric Raymond, however, left with a 
splash.

It's not common, but it's not unheard of. Anybody who thinks that 
developers don't have huge egos probably haven't ever met a software 
engineer. And I suspect kernel people have bigger egos than most. No 
wonder there are clashes every once in a while - it's a wonder there 
aren't _more_ of them.

> How and why? And is it due to a deeper problem?

Well, one part of it is that the way to make changes in the kernel 
community is to do them incrementally.

Small and incremental improvements are much easier to merge. If you go off 
and rewrite a subsystem, you shouldn't expect it to get merged, at least 
not unless it can live side-by-side with the old one (the new firewire 
stack is an example of that, and most filesystems are this way too). And 
the closer to some central part you get, the harder that gets.

So the *bulk* of the kernel stuff can be handled either incrementally, or 
side-by-side, and as a result, you actually seldom see issues like this. 
The kernel is extremely modular, and a large reason for that is exactly to 
avoid couplings.

Some (very few) things cannot be done incrementally. That's why I bring 
up CML2 as a fairly good example of this having happened before. Some 
things require flag-days. But you should pretty much *assume* that if 
there is a flag-day, and if there is a maintainer, the maintainer has to 
be involved.

Does "maintainership" give infinite powers? No. I'll take patches that 
bypass maintainers, but there needs to be some reason for them (ie in some 
sense the maintainer needs to have done a bad job, or the patch just needs 
to be trivial enough - or it cuts across maintainership areas - that it's 
not even _worth_ going through all maintainers).

So maintainers aren't "everything". But they are important. You can't just 
ignore them and go do your own thing, and then expect it to be merged.

			Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Con Kolivas]

Interesting... Trying to avoid reading email but with a flooded inbox it's 
quite hard to do.

A lot of useful discussion seems to have generated in response to people's 
_interpretation_ of my interview rather than what I actually said. For 
example, everyone seems to think I quit because CFS was chosen over SD (hint: 
it wasn't). Since it's generating good discussion I'll otherwise leave it as 
is.


As a parting gesture; a couple of hints for CFS. 

Any difference in behaviour between CFS and SD since they both aim for 
fairness would come down to the way they interpret fair. Since CFS accounts 
sleep time whereas SD does not, that would be the reason.

As for volanomark regressions, they're always the sched_yield implementation. 
SD addressed a similar regression a few months back.

Good luck.

-- 
-ck

Re: [ck] Re: Linus 2.6.23-rc1

[Charles philip Chan]

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

Con Kolivas <kernel@kolivas.org> writes:

> Interesting... Trying to avoid reading email but with a flooded inbox
> it's quite hard to do.

Con, good to hear from you. Good luck with your future endeavors.

Charles

-- 
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?"
(By Matt Welsh)

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

Re: [ck] Re: Linus 2.6.23-rc1

[Roman Zippel]

Hi,

On Sat, 28 Jul 2007, Linus Torvalds wrote:

> We've had people go with a splash before. Quite frankly, the current 
> scheduler situation looks very much like the CML2 situation. Anybody 
> remember that? The developer there also got rejected, the improvement was 
> made differently (and much more in line with existing practices and 
> maintainership), and life went on. Eric Raymond, however, left with a 
> splash.

Since I was directly involved I'd like to point out a key difference.

http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and 
initially I didn't plan on writing a new config system. At the beginning 
there was only the converter, which I did to address the issue that Eric 
created a complete new and different config database, so the converter was 
meant to create a more acceptable transition path. What happened next is 
that I haven't got a single response from Eric, so I continued hacking on 
it until was complete.

The key difference is now that Eric refused the offered help, while Con 
was refused the help he needed to get his work integrated.

When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had 
already pretty much lost. I have no doubt that Ingo can quickly transform 
an idea into working code and I would've been very surprised if he 
wouldn't be able to turn it into something technically superior. When Ingo 
figured out how to implement fair scheduling in a better way, he didn't 
use this idea to help Con to improve his work. He decided instead to 
work against Con and started his own rewrite, this is of course his right 
to do, but then he should also accept the responsibility that Con felt his 
years of work ripped apart and in vain and we have now lost a developer 
who tried to address things from a different perspective.

bye, Roman

Re: [ck] Re: Linus 2.6.23-rc1

[Carlo Florendo]

Roman Zippel wrote:
> When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had 
> already pretty much lost. I have no doubt that Ingo can quickly transform 
> an idea into working code and I would've been very surprised if he 
> wouldn't be able to turn it into something technically superior. When Ingo 
> figured out how to implement fair scheduling in a better way, he didn't 
> use this idea to help Con to improve his work. He decided instead to 
> work against Con and started his own rewrite, this is of course his right 
> to do, but then he should also accept the responsibility that Con felt his 
> years of work ripped apart and in vain and we have now lost a developer 
> who tried to address things from a different perspective.

When Ingo wrote something that went head-on with what Con wrote, it was his 
prerogative to do so.  There's no speaking here of rights to do or not to 
do since as matter of evidence, in the open source world, that which is 
superior (i.e. code, function, not person) has the right to exist and the 
inferior to die away.  Did Ingo have the obligation to improve Con's work? 
  Definitely not.  Did Con have a right to get Ingo's improvements or 
suggestions? Definitely not.  There are no such rights in this open source 
development framework (TM).

What Ingo did, I think, was what he wanted and he has the right to do that. 
       I believe that Ingo does not have an obligation to be responsible 
for what Con felt.  You feel what you feel because you choose to feel that 
way. Let us remember that "Happiness is a choice, not a state."

And let's just look at the attitudes on how both Ingo and Con reacted to 
the issues regarding their respective schedulers.  I won't list them here 
now since they're all there in the archives.

Since attitude also plays a big part in getting your code in mainline, I 
think we would know the reason why one got chosen for the other.

Thank you very much.

Best Regards,

Carlo



-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

RE: [ck] Re: Linus 2.6.23-rc1

[Hua Zhong]

> Did Ingo have the obligation to improve Con's work? Definitely not.
> Did Con have a right to get Ingo's improvements or
> suggestions? Definitely not.

Yes, and that's where the inequality is.

Unless the maintainer does a really bad job or pisses off Linus,
anyone who wants to merge his code into mainline pretty much
has to get the blessing of the maintainer. On the other hand,
as you just said, the maintainer has no such obligation.

> There are no such rights in this open source
> development framework (TM).
> 
> What Ingo did, I think, was what he wanted and he has the right to do
> that.

I think it's the maintainer's privilege, not right.

> in the open source world, that which is superior (i.e. code, function, 
> not person) has the right to exist and the inferior to die away.  

I don't think it's the code superiority that decided the fate of the two
schedulers. When CFS came out, the fate of SD was pretty much already
decided. The fact is that Linus trusts Ingo, and as such he wants to merge
Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this
it through years of hard work, but let's not kid ourselves and deny the
obvious fact.

I think Con was simply too frustrated after years of rejection. He could
have been more diplomatic this time round. But no matter how he'd have
done, once Ingo decided to write a new scheduler, the outcome was pretty
much already decided.

SD (and years of Con's work) inspired CFS. This is a fact. No matter how
smart and capable Ingo is, he needs inspiration to keep the good work going.
So I wish Ingo could work more closely with others and let them share a bit
more credit which would just produce even better work.

Hua

RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Arjan van de Ven]

On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote:
> > Did Ingo have the obligation to improve Con's work? Definitely not.
> > Did Con have a right to get Ingo's improvements or
> > suggestions? Definitely not.
> 
> Yes, and that's where the inequality is.
> 
> Unless the maintainer does a really bad job or pisses off Linus,
> anyone who wants to merge his code into mainline pretty much
> has to get the blessing of the maintainer. On the other hand,
> as you just said, the maintainer has no such obligation.


I think a lot of people are missing some key things here:

It does not matter who's code gets merged.

The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast
improvement mode, and competed on all fronts and borrowed heavily from
eachother in terms of ideas that worked, and innovated to stay ahead.
The end result is that both were good schedulers, and Linux won by
getting the fruit of this competition. Think of it as a mini-evolution
of scheduler ideas compressed into a short time period.

Now compare this to a single patch without competition/the need to
survive in the habitat, say the first SD or the first CFS patch....
whatever your poison is. If there had been no competition element, we
would have ended up with either one of those, and it would have been not
nearly as good as they both ended up as in the end.

Who wrote the code is not relevant in the large picture, the fact that
the problem at hand (2.6 scheduler behavior) got solved is. 

I wish people would focus less on who wrote the actual code that got
merged in the end, and more on the problem that got solved.... People
who care about the desktop should be happy that the scheduler improved a
lot due to the competition where the two new schedulers were hair-close
in most aspects. Again.. think about the problem being solved. Not who
wrote the code or which of the competitive patches got merged in the
end.

Let me repeat the key message:

It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.

What matters is that the problem gets solved and that the Linux kernel
innovates forward.


I've had several cases myself where I spent quite some time solving a
problem, just to get some random remark from someone smart on lkml
saying "if you had done <this simple thing> you would have had <this
simple and superior solution>". Was I pissed off that my patch didn't
get merged but that this better approach got picked? NO! The problem
that I needed to solve got solved in a really good way. Mission
accomplished.

(and merging the code that is cleaning up/smallest is a reasonable one
to pick for someone like Linus, likewise for the "which is likely to be
maintained best" arguments)


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Carlo Florendo]

Arjan van de Ven wrote:
> Let me repeat the key message:
> 
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> 
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.

This, I think, is what really really matters in the end.

> I've had several cases myself where I spent quite some time solving a
> problem, just to get some random remark from someone smart on lkml
> saying "if you had done <this simple thing> you would have had <this
> simple and superior solution>". Was I pissed off that my patch didn't
> get merged but that this better approach got picked? NO! The problem
> that I needed to solve got solved in a really good way. Mission
> accomplished.
> 
> (and merging the code that is cleaning up/smallest is a reasonable one
> to pick for someone like Linus, likewise for the "which is likely to be
> maintained best" arguments)

Very rational.  I would now have to contend that CFS didn't lose and 
neither did SD.  Linux won.

Thank you very much.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[jos]

On 8/1/07, Arjan van de Ven <arjan@infradead.org> wrote:
> Let me repeat the key message:
>
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
>
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.

And, from a standpoint of ONGOING, long-term innovation: what matters
is that brilliant, new ideas get rewarded one way or another. Because
if you don't, the people with the 'different' ideas walk away, you end
up with only those who 'fit' the culture, and there goes innovation.

That's why I tried to get involved in this discussion. It doesn't
matter who's code gets merged. But it does matter that people get
scared away. It took the kernel folks a few years, but they managed to
get someone kicked out who's not 'in-crowd', who clearly has a
different view, and who has the intent and motivation to write and
maintain code.

And that's bad.

I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes.

Of course that's 'overdone', but it conveys a point: If you focus too
much on exploiting current code, instead of fundamentally exploring
new ideas you go down in the long run. There has to be a balance. And
in some area's of the kernel, there seems to be a good balance - new
ideas come in, code is being re-factored. But in scheduling and VM, I
wonder if there's enough exploration...

I hear 'We don't do politics' a lot in the kernel community.

Well, what are politics? Managing the way code gets into the kernel?
That's important for sure, right? And what about thinking about the
hacker culture? Nobody would object to preserving and securing that.
But those are not just technical matters. Yet they require thought. If
the kernel culture doesn't work, the code won't work. There is a
delicate balance, and a key part of what Linus has been doing is
preserving it. I think he must not ignore that there is always room
for improvement, and moments like these (where a big 'fight' is going
on, and there is a clear sense of urgency about the matter) are the
perfect times for a good discussion, and possible change.

Use it.


Love,

Jos



* Disclaimer:
- I'm no kernel hacker
- actually I help at the KDE project in the area of marketing...
- yet, i have followed Con and his stuff for years
- and I do research in the area of promoting innovation in
organisations at a Dutch research institute, which is why I so
annoyingly think I might have something to say.

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Arjan van de Ven]

On Wed, 2007-08-01 at 10:14 +0200, jos@mijnkamer.nl wrote:
> On 8/1/07, Arjan van de Ven <arjan@infradead.org> wrote:
> > Let me repeat the key message:
> >
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> >
> > What matters is that the problem gets solved and that the Linux kernel
> > innovates forward.
> 
> And, from a standpoint of ONGOING, long-term innovation: what matters
> is that brilliant, new ideas get rewarded one way or another.

and in this case, the reward is that the idea got used and credit was
given....

>  Because
> if you don't, the people with the 'different' ideas walk away, you end
> up with only those who 'fit' the culture, and there goes innovation.

yet at the same time if people walk away just because their code didn't
get used, even though their problem got solved, should we merge "worse"
code just to prevent that ? That's almost blackmail, and also just
stupid.

(not suggesting that SD in this case was better or worse, just trying to
make a general point)

> That's why I tried to get involved in this discussion. It doesn't
> matter who's code gets merged. But it does matter that people get
> scared away. It took the kernel folks a few years, but they managed to
> get someone kicked out who's not 'in-crowd', who clearly has a
> different view, and who has the intent and motivation to write and
> maintain code.

And he did manage to get some of his code in, just not all. He also
managed to get people interested in his problem so much that a healthy
stint of competition happened and his problem got solved. If people walk
away because they don't 100% always get things done EXACTLY their way..
well so be it.

> Of course that's 'overdone', but it conveys a point: If you focus too
> much on exploiting current code, instead of fundamentally exploring
> new ideas you go down in the long run. 

here's the thing. Fair scheduling DID get explored. deeply so.

now, getting people interested in your problem (and that is needed to
get them to pay attention to it) is a sales job, no ifs and buts there.
You need to convince them that 1) the problem is real, 2) the problem is
relevant. If you also have a proposed solution you also need to convince
them that 3) the solution solves the problem and 4) that it's the right
way to solve the problem. That isn't politics, it's part of how the
ecosystem works; people are not stupid, but you need to convince them
about your problem and solution. And that "default a bit skeptical and
overworked" approach is the foundation of the process; the same way as
you need to pass a code review before people will merge your code.
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Hua Zhong]

> > And, from a standpoint of ONGOING, long-term innovation: what matters
> > is that brilliant, new ideas get rewarded one way or another.
> 
> and in this case, the reward is that the idea got used and credit was
> given....

You mean, when Ingo announced CFS he mentioned Con's name?

I really doubt that is the best reward for a developer.

> > Because if you don't, the people with the 'different' ideas walk away,
> > you end up with only those who 'fit' the culture, and there goes
innovation.
> 
> yet at the same time if people walk away just because their code didn't
> get used, even though their problem got solved, should we merge "worse"
> code just to prevent that ? That's almost blackmail, and also just
> stupid.
> 
> (not suggesting that SD in this case was better or worse, just trying
> to make a general point)

If it is a general point, sure, but it's hardly 1/10 of what happened
here. And note I don't agree with Con's decision either - I wish he'd
be back, but the reason I jumped in was to show some understanding, as
I see some comments in the thread that were not doing so.

When you said "it does not matter whose code got merged", I have to
disagree. Sure, for the Linux community as a whole, for Linux itself,
it may not matter, but for the individuals involved, it does. And I
think benefits of individuals are as important as benefits of the
community (or the nation).

Con has been working on scheduler (fair or not) for years, and nothing
got merged. Yet CFS got merged in a blink despite the fact that the
competition just began to show. Have we given SD a fair chance? No.

Ingo has a unique position that nobody else could challenge. Note I
have said that he earned it through hard work and talent, so that's
not the problem. The problem is how he could have handled it better,
not "grab the food right under other's nose" blatantly.

I don't think merging CFS was a wrong decision. The problem was how
this decision was made. And I think Linus made some rather unfair
comments about Con's personality, and I don't think deeply that
was the reason he merged Ingo's code.

Hua

RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Arjan van de Ven]

On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote:
> > > And, from a standpoint of ONGOING, long-term innovation: what matters
> > > is that brilliant, new ideas get rewarded one way or another.
> > 
> > and in this case, the reward is that the idea got used and credit was
> > given....
> 
> You mean, when Ingo announced CFS he mentioned Con's name?

and put his name in the code too


> When you said "it does not matter whose code got merged", I have to
> disagree. Sure, for the Linux community as a whole, for Linux itself,
> it may not matter, but for the individuals involved, it does. And I
> think benefits of individuals are as important as benefits of the
> community (or the nation).

I agree it's a nice ego boost to see your code merged.
But... do you care more about your ego boost or about your problem
getting solved? I really want to change this if you say "ego for code
merging"... "ego boost for getting linux improved and being involved in
solving an important problem" is a lot better type of ego boost..

No developer can or should expect that most, or even half of his code to
be merged. Even Linus doesn't get half the code he writes into linux :)

Con did get a whole bunch of stuff merged over the years, and for the
rest he mostly got the problem solved. That's pretty successful....

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Andrea Arcangeli]

On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote:
> I've had several cases myself where I spent quite some time solving a
> problem, just to get some random remark from someone smart on lkml
> saying "if you had done <this simple thing> you would have had <this
> simple and superior solution>". Was I pissed off that my patch didn't
> get merged but that this better approach got picked? NO! The problem
> that I needed to solve got solved in a really good way. Mission
> accomplished.

Hey to me it even happened I had this nice and safe pte-highmem patch
but the buggy highpte was merged instead, go figure. Con got lucky.

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Frank Ch. Eigler]

Arjan van de Ven <arjan@infradead.org> writes:

> [...]
> It does not matter [whose] code gets merged.
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.
> [...]

This attitude has risks over the long term, if outsiders with fresh
ideas are discouraged.  Risking becoming known to defer too much to
established maintainers, those fresh ideas may stop coming to linux.

- FChE

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Arjan van de Ven]

On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> 
> > [...]
> > It does not matter [whose] code gets merged.
> > What matters is that the problem gets solved and that the Linux kernel
> > innovates forward.
> > [...]
> 
> This attitude has risks over the long term, if outsiders with fresh
> ideas are discouraged.  Risking becoming known to defer too much to
> established maintainers, those fresh ideas may stop coming to linux.

My concern is that only "get my line of code merged" is seen as "the
ultimate thing". It's more than that. Linux is about collaboration,
where it matters more that people work together to solve a problem, far
far more than who actually types the lines in on the keyboard. Working
on the problem should be seen (and recognized) as the right thing. Who
writes the code is secundary to that.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!

[Frank Ch. Eigler]

Hi -

> My concern is that only "get my line of code merged" is seen as "the
> ultimate thing". It's more than that. Linux is about collaboration [...]

Unfortunately, this spirit of collaboration sometimes gets lost in
practice when feedback is asymmetric, obnoxious, or absent.

- FChE

Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter whose code gets merged!

[Daniel Phillips]

On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> > [...]
> > It does not matter [whose] code gets merged.
> > What matters is that the problem gets solved and that the Linux
> > kernel innovates forward.
> > [...]
>
> This attitude has risks over the long term, if outsiders with fresh
> ideas are discouraged.  Risking becoming known to defer too much to
> established maintainers, those fresh ideas may stop coming to linux.

Amen to that, Frank.  Driving off talented contributers is a Very Bad 
Thing for Linux in the long run.  This will not not stop evolutionary 
progress, but it slows it down and may result in an overly inbred 
animal.

It is especially easy to drive off a contributor whose day job is not 
Linux hacking.

Regards,

Daniel

Re: [ck] Re: Linus 2.6.23-rc1

[Carlo Florendo]

Hua Zhong wrote:

> I don't think it's the code superiority that decided the fate of the two
> schedulers. When CFS came out, the fate of SD was pretty much already
> decided. The fact is that Linus trusts Ingo, and as such he wants to merge
> Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this
> it through years of hard work, but let's not kid ourselves and deny the
> obvious fact.

I agree with you here.  It's not simply code superiority that matters but a 
balance of attitude and the code's corroboration with numbers.  Both had 
numbers to show but I think that one's attitude was preferred over the other.

> I think Con was simply too frustrated after years of rejection. He could
> have been more diplomatic this time round. But no matter how he'd have
> done, once Ingo decided to write a new scheduler, the outcome was pretty
> much already decided.
> 
> SD (and years of Con's work) inspired CFS. This is a fact. No matter how
> smart and capable Ingo is, he needs inspiration to keep the good work going.
> So I wish Ingo could work more closely with others and let them share a bit
> more credit which would just produce even better work.

I don't see where credit was lacking.  As far as I've observed, SD's author 
was given acknowledgment on what he did and even got praise.

Thank you very much.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: [ck] Re: Linus 2.6.23-rc1

[Alan Cox]

> has to get the blessing of the maintainer. On the other hand,
> as you just said, the maintainer has no such obligation.

Umm nope. As a maintainer if you feed Linus stuff you wrote that he
thinks is a bad idea it will not go in, and you'll get an explanation of
why. 

The process isn't perfect (eg removing half-vanished maintainers isnt
handled well) but it isn't as you claim.

Re: [ck] Re: Linus 2.6.23-rc1

[Jory A. Pratt]

On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote:

> As a long-term maintainer, trust me, I know what matters. And a person who 
> can actually be bothered to follow up on problem reports is a *hell* of a 
> lot more important than one who just argues with reporters.
> 
> 			Linus
	Once again linus blows a nut getting off about this and that. The fact
of the matter linus is a one sided. The fact is linus says what he wants
and people think he is god. The fact is noone get code in unless they
are a major player in a linux distro. Ingo had much advantage by using
fedora users. The fact Con did not take all bugs serious yes that is a
player of the game but linus is GOD so all bow before him before he
blows his back out while jacking off to his rants about how the kernel
and other projects should run.

		Jory

Re: Linus 2.6.23-rc1

[Ingo Molnar]

hi Kasper,

* Kasper Sandberg <lkml@metanurb.dk> wrote:

> Im still not so keen about this, Ingo never did get CFS to match SD in 
> smoothness for 3d applications, where my test subjects are quake(s), 
> world of warcraft via wine, unreal tournament 2004. And this is 
> despite many patches he sent me to try and tweak it. [...]

hey, i thought you vanished from the face of the earth :-) The last 
email i got from you was more than 2 months ago, where you said that 
you'll try the latest CFS version as soon as possible but that you were 
busy with work. I sent 2 more emails to you about new CFS versions but 
then stopped pestering you directly - work _does_ take precedence over 
games =B-)

CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went 
upstream, there were no 3D related CFS regressions open for quite some 
time and because i never heard back from you i assumed everything's 
peachy.

In any case i'm glad you found the time to try CFS again, so please let 
me know in what way it regresses. In your most recent emails you did not 
indicate what specific problem you are having (and you did not reply to 
my last emails from May) - are your old regression reports against CFS 
v13 from May still true as of v2.6.23-rc1? If they are, could you please 
indicate which specific report of yours describes it best and send me 
(or upload to some webspace) the specific .config you are using on your 
box, and the cfs-debug-info.sh snapshot taken when you are running your 
game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest 
quality debug output) You can pick the script up from:

  http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh

Giving us that info would help us immensely with tracking down any CFS 
problem you might still be having.

Or, if you feel adventurous enough to look into the internals of the 
kernel (which, considering your offer to take up SD maintenance, you 
must be ;-), here's my kernel latency tracer:

   http://people.redhat.com/mingo/latency-tracing-patches/

( see: latency-tracer-v2.6.23-rc1-combo.patch )

the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set 
/proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to 
thus measure raw worst-case scheduler latencies - if you regularly see 
the kernel report above say 1000 usecs latencies to the syslog, on a 
PREEMPT kernel then there's definitely something foul going on. For 
example, that's how i found an audio playback latency problem in an 
early version of CFS:

(            sshd-14614|#1): new 5 us maximum-latency wakeup.
(          ogg123-6603 |#1): new 6 us maximum-latency wakeup.
(          ogg123-6608 |#1): new 6 us maximum-latency wakeup.
(            sshd-14614|#1): new 10 us maximum-latency wakeup.
(          ogg123-6607 |#0): new 15 us maximum-latency wakeup.
(        events/0-9    |#0): new 789 us maximum-latency wakeup.
(          ogg123-6603 |#0): new 2566 us maximum-latency wakeup.

that 2.5 msecs latency in the ogg123 task was definitely the sign of a 
kernel bug.

If plain WAKEUP_TIMING does not show anything suspicious, you can use 
the latency tracer in more advanced ways as well to trace the whole 
system and figure out the precise cause of your game latencies - i'll be 
glad to help with that if no simpler measure helps. [see trace-it.c for 
some of those details.]

> [...] As far as im concerned, i may be forced to unofficially maintain 
> SD for my own systems(allthough lots in the gaming community is bound 
> to be interrested, as it does make games lots better)

i'd encourage you to do it - in fact i already tried to prod Peter 
Williams into doing exactly that ;) The more reality checks a scheduler 
has, the better. [ Btw., after the obvious initial merging trouble it 
should be much easier to keep SD maintained against future upstream 
kernels due to the policy modularity that CFS introduces. (and which 
policy-modularity should also help reduce the size and complexity of the 
SD patch.) ]

Thanks,

	Ingo

Re: Linus 2.6.23-rc1

[George Sescher]

> * Kasper Sandberg <lkml@metanurb.dk> wrote:
> > [...] As far as im concerned, i may be forced to unofficially maintain
> > SD for my own systems(allthough lots in the gaming community is bound
> > to be interrested, as it does make games lots better)

On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> i'd encourage you to do it - in fact i already tried to prod Peter
> Williams into doing exactly that ;) The more reality checks a scheduler
> has, the better. [ Btw., after the obvious initial merging trouble it
> should be much easier to keep SD maintained against future upstream
> kernels due to the policy modularity that CFS introduces. (and which
> policy-modularity should also help reduce the size and complexity of the
> SD patch.) ]

<chuckle>

You're advocating plugsched now?

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Mon, 30 Jul 2007, George Sescher wrote:
> <chuckle>
> 
> You're advocating plugsched now?

I'd suggest people here take a look at the code. It's not what Ingo was 
saying, and it's not what the code is set up to do. He's just stating that 
the way he split up the files, it's actually easier from a patching 
standpoint to just create a new file to include instead of 
"kernel/sched_fair.c".

But quite frankly, I've seen a lot of totally stupid flamage, and very 
little actual sense in this discussion. People probably didn't even look 
at the patches. Did you?

For example, how hard is it for people to just admit that CFS actually 
does better than SD on a number of things? Including very much on the 
desktop. 

Ingo posted numbers. Look at those numbers, and then I would suggest some 
people could seriously consider just shutting up. I've seen too many 
idiotic people who claim that Con got treated unfairly, without those 
people admitting that maybe I had a point when I said that we have had a 
scheduler maintainer for years that actually knows what he's doing.

And no, it has never been about "desktop" vs "servers", or similar 
claptrap. It's been about improving the scheduler.

		Linus

Re: Linus 2.6.23-rc1

[George Sescher]

> On Mon, 30 Jul 2007, George Sescher wrote:
> > <chuckle>
> >
> > You're advocating plugsched now?

On 30/07/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I'd suggest people here take a look at the code. It's not what Ingo was
> saying, and it's not what the code is set up to do. He's just stating that
> the way he split up the files, it's actually easier from a patching
> standpoint to just create a new file to include instead of
> "kernel/sched_fair.c".

<snip long other discussion unrelated to my question>

Ingo's origiinal comment:

On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> i'd encourage you to do it - in fact i already tried to prod Peter
> Williams into doing exactly that ;) The more reality checks a scheduler
> has, the better.

He said having reality checks is a good thing. He's encouraging some
poor bastard to maintain plugsched out of mainline to have SD or
whatever to compare to. I did not say I advocated anything whatsoever.
I was asking if this is what Ingo is suggesting people use their
energy doing. Not good enough for mainline, but definitely worth
keeping around and good enough for... no idea what. I was asking Ingo
that.

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Mon, 30 Jul 2007, George Sescher wrote:
> 
> He said having reality checks is a good thing. He's encouraging some
> poor bastard to maintain plugsched out of mainline to have SD or
> whatever to compare to.

My bad, it was me who  misread that (I didn't react to the name, I was 
thinking people were talking about maintaining SD that way).

Mea culpa.

		Linus

Re: [ck] Re: Linus 2.6.23-rc1

[Matthew Hawkins]

On 7/30/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> For example, how hard is it for people to just admit that CFS actually
> does better than SD on a number of things? Including very much on the
> desktop.

Actually in benchmarks Ingo has quoted, SD was better on the desktop
(by a small margin).
CFS is still a bit bursty, though it has significantly improved with
age.  I know, I did those benchmarks.  That being said, I'm really
glad to see CFS in your git tree because the new framework around it
really improves the readability of the code, and actually makes it
easier to start experimenting with scheduler improvements from an
entire scheduler like SD to minor bits like priorities.

I have one concern - my benchmarking took load average as the common
denominator and CFS alters the way the load average is calculated, so
perhaps it wasn't a fair comparison.  That being said, they still
showed CFS could scale very well and SD did not, so considering we're
dealing with everything from wristwatches to BlueGene/L I believe the
right choice was made.  Those arguing for the 2% improvement that SD
would give them in their environment would be better off

a) helping port SD to the new scheduler framework
b) assisting Ingo in improving CFS to meet/exceed their requirements
c) giving practical assistance to anyone doing either of the above

I'm re-learning git and using my Copious Spare Time (tm) to do what I
can - but I have to admit I'm really in over my head.  But hey, if
Jeff Garzik can do it, so can I.  I remember when he couldn't grok C &
now he's got control over all our data :-)

-- 
Matt

Re: Linus 2.6.23-rc1

[Bill Huey]

On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote:
> Ingo posted numbers. Look at those numbers, and then I would suggest some 
> people could seriously consider just shutting up. I've seen too many 
> idiotic people who claim that Con got treated unfairly, without those 
> people admitting that maybe I had a point when I said that we have had a 
> scheduler maintainer for years that actually knows what he's doing.

Here's the problem, *a lot* of folks can do scheduler development in and
outside community, so what's with exclusive-only attitude towards the
scheduler ?

There's sufficient effort coming from folks working on CFS from many
sources so how's sched-plugin a *threat* to stock kernel scheduler
development if it gets to the main tree as the default compile option ??

Those are the core question that Con brought in the APC article, folks
are angry because and nobody central to the current Linux has address
this and instead focused on a single narrow set of technical issues
to justify a particular set of actions.

I mean, I'm not the only that has said this so there has to be some
kind of truth behind it.

bill

Re: Linus 2.6.23-rc1

[Ingo Molnar]

* Bill Huey <billh@gnuppy.monkey.org> wrote:

> Here's the problem, *a lot* of folks can do scheduler development in 
> and outside community, so what's with exclusive-only attitude towards 
> the scheduler ?

You came to us as an ex-BSD developer (which has a completely different 
contribution culture) and early on i tried to explain to you (and we met 
in person at OLS2004) that the Linux way of getting code upstream is not 
that of social-engineering or talking the code upstream, but that of 
_coding_ your stuff upstream: working with others and getting good code 
accepted. I'm not sure you ever realized that point.

To counter your myth of "upstream development exclusivity", here are 
some git-provided hard numbers. Since 2.6.22 was released 3 weeks ago, 
over half a million lines of code were added/modified/removed in the 
upstream -git kernel:

 5965 files changed, 332689 insertions(+), 269500 deletions(-)

that massive amount of work was done by over 750 contributors. Out of 
those 750 contributors, more than 160 are _first time contributors_. 
Think about it, there's _lots_ of fresh blood, about 650 new kernel 
contributors a year. The kernel/sched.c file itself, with 274 commits 
and 88 unique contributors over the past ~2 years alone is one of the 
most actively and most diversely developed core kernel subsystems in the 
kernel.

Regarding PlugSched, i'd suggest you to read the detailed explanation 
that has been offered in this and in related discussions over the past 
few years on lkml. (see: http://lkml.org/lkml/2007/4/15/124 and 
http://lkml.org/lkml/2007/4/15/64 and many other postings)

To recap: we dont have a pluggable TCP/IP core either. Nor do we have a 
pluggable MM. Pluggable I/O schedulers are not an unconditional success 
either - Nick (I/O scheduler author) recently stated that and suggested 
the CPU scheduler to not be pluggable.

Whether something becomes pluggable or not depends on many 
_technological_ factors but you appear to be dead-set on spinning _any_ 
technical decision against pluggability into a conjured-up non-sequitor 
non-technical "so this means you have an exclusive-only attitude" 
position.

Why do you do that? Why cannot you accept the plain fact that:

  _in a kernel, some things should not be pluggable_

Simple as that. I am still in favor of PlugSched as a nice external 
patch because it keeps people interested in schedulers and keeps the 
competitive pressure up even higher (and other reasons), but there are 
_stronger factors than that_ against its inclusion into mainline. (see 
those many mails about those factors)

Besides the technological advantages, the competitive pressure can be 
_even higher_ if the 'competition' is not in-tree but out-of-tree - and 
the end result is an ultimately better scheduler. Had we not rejected 
PlugSched 4 years ago CFS could easily never have happened. We'd have 
2-3 mediocre schedulers, instead of one good scheduler and _users_ would 
resist the removal of any of those schedulers, so no clear winner could
ever gain enough momentum and Linux would forever be stuck with a stupid
and inferior "you have to tweak the scheduler selection manually to your
workload to get the max out of the system" handicap.

But ... i can also understand it that you as a _person_ are unhappy:

You were quite unhappy and bitter about me not including your lockstat 
patch in -rt, while all that happened was that for months i (and others) 
told you that the lockstat idea is nice and sound and tried to point it 
out to you how much simpler and more elegant it would be to use the 
lockdep infrastructure for the same purpose and tried to encourage you 
to pick that route. Peter Zijlstra implemented that approach meanwhile, 
and he used around a magnitude less code than your patch did. That code 
is upstream now. _You_ could have been the one who did that, and it was 
you who prevented yourself from having done that major contribution to 
Linux lock instrumentation.

Perhaps partly influenced by your negative lockstat experience, you were 
also the first one who brought up the (pretty bogus) "elitist" "old 
guard" argument [ http://lkml.org/lkml/2007/4/14/115 ] as a reply to my 
initial CFS announcement, and shortly after your mail Con wrote his 
infamous outburst against CFS [ http://lkml.org/lkml/2007/4/14/199 ], to 
which you came up with another bogus "the main failure I see here is 
that Con wasn't included in this design or privately in review process" 
reply [ http://lkml.org/lkml/2007/4/15/4 ] that only fanned the flames.

I believe by doing so you poured the oil of your own bitterness on his 
fire, thinly masked as neutral constructive criticism.

So in my opinion you are far from being an unbiased observer in this 
matter, you keep repeating your old arguments without apparently 
listening to the replies and thus i doubt anything i say could really 
make you 'happy' :-/

Really, i'd love it if you started contributing to Linux in a major way, 
instead of doing what seems to amount to stirring up personal 
controversy, and i believe the only inhibitor to such positive kernel 
contributions is _yourself_. If you spent half of the energy you are 
spending on writing these emails on producing actual code you could have 
become a maintainer of some nice Linux subsystem easily. (as many other 
people have become that who came to Linux much later than you) That door 
is still not closed of course, and i believe it all only depends on you, 
not on any upstream maintainer.

	Ingo

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Tue, 31 Jul 2007, Bill Huey wrote:
> 
> Here's the problem, *a lot* of folks can do scheduler development in and
> outside community, so what's with exclusive-only attitude towards the
> scheduler ?

There is no exclusive-only attitude towards the scheduler.

If you send me small and obvious improvements, they'll get applied to the 
scheduler, exactly the same way they get applied to anything else.

And if you try to rewrite everything, and do it on your own, and then 
don't even send me a patch, it also won't get applied. 

Surprise?

			Linus

Re: Linus 2.6.23-rc1

[Ingo Molnar]

* George Sescher <gesacs@gmail.com> wrote:

> On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > i'd encourage you to do it - in fact i already tried to prod Peter 
> > Williams into doing exactly that ;) The more reality checks a 
> > scheduler has, the better. [ Btw., after the obvious initial merging 
> > trouble it should be much easier to keep SD maintained against 
> > future upstream kernels due to the policy modularity that CFS 
> > introduces. (and which policy-modularity should also help reduce the 
> > size and complexity of the SD patch.) ]
> 
> <chuckle>
> 
> You're advocating plugsched now?

hm, the way you posited this question implies that you see an 
inconsistency in my position or that it surprised you - i cannot explain 
the '<chuckle>' in any other way :) Which bit do you see as inconsistent 
and/or which bit surprised you and why?

        Ingo

Re: Linus 2.6.23-rc1

[George Sescher]

> > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > i'd encourage you to do it - in fact i already tried to prod Peter
> > > Williams into doing exactly that ;) The more reality checks a
> > > scheduler has, the better. [ Btw., after the obvious initial merging
> > > trouble it should be much easier to keep SD maintained against
> > > future upstream kernels due to the policy modularity that CFS
> > > introduces. (and which policy-modularity should also help reduce the
> > > size and complexity of the SD patch.) ]

> * George Sescher <gesacs@gmail.com> wrote:
> > <chuckle>
> >
> > You're advocating plugsched now?

On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> hm, the way you posited this question implies that you see an
> inconsistency in my position or that it surprised you - i cannot explain
> the '<chuckle>' in any other way :) Which bit do you see as inconsistent
> and/or which bit surprised you and why?

The idea is not good enough for mainline and has no place in mainline
yet you say it's very important to maintain it... but out of mainline.
Place the responsibility of keeping mainline's performance in check
"reality check as you called it" on to someone who is forced to
develop out of mainline? I have zero interest one way or the other
myself, but how can one not chuckle?

Again I have no interest either way but if this is that important a
reality check that it needs maintaining it should be oh I don't know,
an -mm only feature or something?

Please don't jump down my throat, your position just needs clarifying.  :-|

Re: Linus 2.6.23-rc1

[Ingo Molnar]

* George Sescher <gesacs@gmail.com> wrote:

> > > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > > i'd encourage you to do it - in fact i already tried to prod Peter
> > > > Williams into doing exactly that ;) The more reality checks a
> > > > scheduler has, the better. [ Btw., after the obvious initial merging
> > > > trouble it should be much easier to keep SD maintained against
> > > > future upstream kernels due to the policy modularity that CFS
> > > > introduces. (and which policy-modularity should also help reduce the
> > > > size and complexity of the SD patch.) ]
> 
> > * George Sescher <gesacs@gmail.com> wrote:
> > > <chuckle>
> > >
> > > You're advocating plugsched now?
> 
> On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > hm, the way you posited this question implies that you see an
> > inconsistency in my position or that it surprised you - i cannot explain
> > the '<chuckle>' in any other way :) Which bit do you see as inconsistent
> > and/or which bit surprised you and why?
> 
> The idea is not good enough for mainline and has no place in mainline 
> yet you say it's very important to maintain it... but out of mainline. 
> Place the responsibility of keeping mainline's performance in check 
> "reality check as you called it" on to someone who is forced to 
> develop out of mainline? I have zero interest one way or the other 
> myself, but how can one not chuckle?

What you should realize is that _all_ future code that goes into Linux 
is 'forced' to be developed 'out of mainline' today. So what you seem to 
characterise via negative terms like 'forced', and what seems to make 
you 'chuckle' (not meant as a compliment either i gather ;), is in fact 
the _very engine_ that keeps Linux running.

And there's no exception: Linus himself creates an "out of mainline" 
fork of Linux every time he develops something new. "Forks" are _the_ 
main mechanism to develop Linux, and it always was. External code is the 
"reality check" of mainline code. It is the 'external pool of genes' 
that is _competing_ against in-tree code.

Sometimes the decision to include new bits of code is easy and positive 
(so it is a "fork" only very briefly and nobody actually ever has enough 
time to think of that code as a "fork"), sometimes it takes some time 
and the decision is positive, sometimes the decision is immediately 
negative and the code is rejected, sometimes it's negative after some 
time. Often code goes through several cycles of rejection before it is 
merged. The larger the code, the more rejections it will see - and that 
is natural. Sometimes, very rarely, out of the hundreds of thousands of 
external changes that went into Linux so far, code seems to be staying 
'in limbo' forever - such as the kernel debugger. So _every_ color of 
the spectrum is present: immediate integration, immediate rejection, 
long-term integration, long-term rejection, ping-pong of rejections 
until integration, and even decisions that seem to take a near 
'eternity' in very rare cases.

If a biologist took a look at these gene pool dynamic parameters alone, 
without knowing a squat about kernel technology, the likely conclusion 
would be that this is "a healthy, diverse gene pool that is being 
affected by many many external factors. A true expert at survival, that 
critter!" ;-)

For example, i'm at the moment maintaining in excess of 400 patches "out 
of mainline", many of which will never see the "daylight of upstream". 
Many of those are longer-term "reality checks" that could replace 
in-tree code in the future or are in the process of replacing in-tree 
code as we speak. Some are "reality checks" that _failed_ to replace 
in-tree code but i'm still maintaining them because i find them useful. 
If the kernel code that these patches modify happens to be modularized 
then it is sometimes helpful to my out-of-tree patches (and sometimes 
it's a pain) - but in any case, i dont "require" nor "suggest" upstream 
maintainers to modularize, just to make my "out of tree" life easier. 
Are they still useful to Linux in general? I sure hope so.

It was always like this in Linux: modularization is mainly dictated by 
the needs of the in-tree code - and that's very much on purpose, and 
always was, to increase the advantages of including good external genes 
in the kernel gene pool.

	Ingo

Re: Linus 2.6.23-rc1

[George Sescher]

> * George Sescher <gesacs@gmail.com> wrote:
>
> > > > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > > > i'd encourage you to do it - in fact i already tried to prod Peter
> > > > > Williams into doing exactly that ;) The more reality checks a
> > > > > scheduler has, the better. [ Btw., after the obvious initial merging
> > > > > trouble it should be much easier to keep SD maintained against
> > > > > future upstream kernels due to the policy modularity that CFS
> > > > > introduces. (and which policy-modularity should also help reduce the
> > > > > size and complexity of the SD patch.) ]
> >
> > > * George Sescher <gesacs@gmail.com> wrote:
> > > > <chuckle>
> > > >
> > > > You're advocating plugsched now?
> >
> > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > hm, the way you posited this question implies that you see an
> > > inconsistency in my position or that it surprised you - i cannot explain
> > > the '<chuckle>' in any other way :) Which bit do you see as inconsistent
> > > and/or which bit surprised you and why?
> >
> > The idea is not good enough for mainline and has no place in mainline
> > yet you say it's very important to maintain it... but out of mainline.
> > Place the responsibility of keeping mainline's performance in check
> > "reality check as you called it" on to someone who is forced to
> > develop out of mainline? I have zero interest one way or the other
> > myself, but how can one not chuckle?

On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> What you should realize is that _all_ future code that goes into Linux
> is 'forced' to be developed 'out of mainline' today. So what you seem to
> characterise via negative terms like 'forced', and what seems to make
> you 'chuckle' (not meant as a compliment either i gather ;), is in fact
> the _very engine_ that keeps Linux running.
>
> And there's no exception: Linus himself creates an "out of mainline"
> fork of Linux every time he develops something new. "Forks" are _the_
> main mechanism to develop Linux, and it always was. External code is the
> "reality check" of mainline code. It is the 'external pool of genes'
> that is _competing_ against in-tree code.
>
> Sometimes the decision to include new bits of code is easy and positive
> (so it is a "fork" only very briefly and nobody actually ever has enough
> time to think of that code as a "fork"), sometimes it takes some time
> and the decision is positive, sometimes the decision is immediately
> negative and the code is rejected, sometimes it's negative after some
> time. Often code goes through several cycles of rejection before it is
> merged. The larger the code, the more rejections it will see - and that
> is natural. Sometimes, very rarely, out of the hundreds of thousands of
> external changes that went into Linux so far, code seems to be staying
> 'in limbo' forever - such as the kernel debugger. So _every_ color of
> the spectrum is present: immediate integration, immediate rejection,
> long-term integration, long-term rejection, ping-pong of rejections
> until integration, and even decisions that seem to take a near
> 'eternity' in very rare cases.
>
> If a biologist took a look at these gene pool dynamic parameters alone,
> without knowing a squat about kernel technology, the likely conclusion
> would be that this is "a healthy, diverse gene pool that is being
> affected by many many external factors. A true expert at survival, that
> critter!" ;-)
>
> For example, i'm at the moment maintaining in excess of 400 patches "out
> of mainline", many of which will never see the "daylight of upstream".
> Many of those are longer-term "reality checks" that could replace
> in-tree code in the future or are in the process of replacing in-tree
> code as we speak. Some are "reality checks" that _failed_ to replace
> in-tree code but i'm still maintaining them because i find them useful.
> If the kernel code that these patches modify happens to be modularized
> then it is sometimes helpful to my out-of-tree patches (and sometimes
> it's a pain) - but in any case, i dont "require" nor "suggest" upstream
> maintainers to modularize, just to make my "out of tree" life easier.
> Are they still useful to Linux in general? I sure hope so.
>
> It was always like this in Linux: modularization is mainly dictated by
> the needs of the in-tree code - and that's very much on purpose, and
> always was, to increase the advantages of including good external genes
> in the kernel gene pool.

<permission to jump down my throat granted now>

Nope. I can't equate your soliloquy about the development process with
what it appears you are doing in the case of plugsched but you're
obviously too smart for me to argue against or I don't understand and
I've already overstepped my authority on this mailing list being an
ordinary user.  I'll just end up trying to extract your boot from my
anus.

Re: Linus 2.6.23-rc1

[Ingo Molnar]

* George Sescher <gesacs@gmail.com> wrote:

> > * George Sescher <gesacs@gmail.com> wrote:
> >
> > > > > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > > > > i'd encourage you to do it - in fact i already tried to prod Peter
> > > > > > Williams into doing exactly that ;) The more reality checks a
> > > > > > scheduler has, the better. [ Btw., after the obvious initial merging
> > > > > > trouble it should be much easier to keep SD maintained against
> > > > > > future upstream kernels due to the policy modularity that CFS
> > > > > > introduces. (and which policy-modularity should also help reduce the
> > > > > > size and complexity of the SD patch.) ]
> > >
> > > > * George Sescher <gesacs@gmail.com> wrote:
> > > > > <chuckle>
> > > > >
> > > > > You're advocating plugsched now?
> > >
> > > On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > > > hm, the way you posited this question implies that you see an
> > > > inconsistency in my position or that it surprised you - i cannot explain
> > > > the '<chuckle>' in any other way :) Which bit do you see as inconsistent
> > > > and/or which bit surprised you and why?
> > >
> > > The idea is not good enough for mainline and has no place in mainline
> > > yet you say it's very important to maintain it... but out of mainline.
> > > Place the responsibility of keeping mainline's performance in check
> > > "reality check as you called it" on to someone who is forced to
> > > develop out of mainline? I have zero interest one way or the other
> > > myself, but how can one not chuckle?
> 
> On 30/07/07, Ingo Molnar <mingo@elte.hu> wrote:
> > What you should realize is that _all_ future code that goes into Linux
> > is 'forced' to be developed 'out of mainline' today. So what you seem to
> > characterise via negative terms like 'forced', and what seems to make
> > you 'chuckle' (not meant as a compliment either i gather ;), is in fact
> > the _very engine_ that keeps Linux running.
> >
> > And there's no exception: Linus himself creates an "out of mainline"
> > fork of Linux every time he develops something new. "Forks" are _the_
> > main mechanism to develop Linux, and it always was. External code is the
> > "reality check" of mainline code. It is the 'external pool of genes'
> > that is _competing_ against in-tree code.
> >
> > Sometimes the decision to include new bits of code is easy and positive
> > (so it is a "fork" only very briefly and nobody actually ever has enough
> > time to think of that code as a "fork"), sometimes it takes some time
> > and the decision is positive, sometimes the decision is immediately
> > negative and the code is rejected, sometimes it's negative after some
> > time. Often code goes through several cycles of rejection before it is
> > merged. The larger the code, the more rejections it will see - and that
> > is natural. Sometimes, very rarely, out of the hundreds of thousands of
> > external changes that went into Linux so far, code seems to be staying
> > 'in limbo' forever - such as the kernel debugger. So _every_ color of
> > the spectrum is present: immediate integration, immediate rejection,
> > long-term integration, long-term rejection, ping-pong of rejections
> > until integration, and even decisions that seem to take a near
> > 'eternity' in very rare cases.
> >
> > If a biologist took a look at these gene pool dynamic parameters alone,
> > without knowing a squat about kernel technology, the likely conclusion
> > would be that this is "a healthy, diverse gene pool that is being
> > affected by many many external factors. A true expert at survival, that
> > critter!" ;-)
> >
> > For example, i'm at the moment maintaining in excess of 400 patches "out
> > of mainline", many of which will never see the "daylight of upstream".
> > Many of those are longer-term "reality checks" that could replace
> > in-tree code in the future or are in the process of replacing in-tree
> > code as we speak. Some are "reality checks" that _failed_ to replace
> > in-tree code but i'm still maintaining them because i find them useful.
> > If the kernel code that these patches modify happens to be modularized
> > then it is sometimes helpful to my out-of-tree patches (and sometimes
> > it's a pain) - but in any case, i dont "require" nor "suggest" upstream
> > maintainers to modularize, just to make my "out of tree" life easier.
> > Are they still useful to Linux in general? I sure hope so.
> >
> > It was always like this in Linux: modularization is mainly dictated by
> > the needs of the in-tree code - and that's very much on purpose, and
> > always was, to increase the advantages of including good external genes
> > in the kernel gene pool.
> 
> <permission to jump down my throat granted now>

heh :) Sorry, but i have to disappoint you on that count :-)

> Nope. I can't equate your soliloquy about the development process with 
> what it appears you are doing in the case of plugsched [...]

could you please be a bit more specific - what do you mean under "what 
you are doing in the case of plugsched"?

In the above section which you characterised as 'soliloquy' (i guess i 
must have failed to make myself clear enough) i tried to answer the 
statement you articulated:

> > > Place the responsibility of keeping mainline's performance in 
> > > check "reality check as you called it" on to someone who is forced 
> > > to develop out of mainline? [...]

by pointing out that "developing out of mainline" (such as PlugSched or 
like the 400+ patches i maintain out of tree), is not something negative 
as you seem to have suggested/implied but the main mechanism of Linux 
development - so not surprisingly, while i might disagree whether 
something out of tree should go upstream or not, i dont disagree with 
the idea of keeping out-of-tree patches - why should i? I do it myself 
and always did it. Or in other words: without out-of-tree patches the 
kernel 'pool of genes' would become stagnant.

If you disagree with me or if you have any other questions then feel 
free and let me know. And as always, i could be mistaken so dont expect 
me to "jump down on your throat" in any way, shape or form :-) Thanks,

	Ingo

Re: Linus 2.6.23-rc1

[Kasper Sandberg]

On Sun, 2007-07-29 at 17:04 +0200, Ingo Molnar wrote:
> hi Kasper,
> 
> * Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > Im still not so keen about this, Ingo never did get CFS to match SD in 
> > smoothness for 3d applications, where my test subjects are quake(s), 
> > world of warcraft via wine, unreal tournament 2004. And this is 
> > despite many patches he sent me to try and tweak it. [...]
> 
> hey, i thought you vanished from the face of the earth :-) The last 
> email i got from you was more than 2 months ago, where you said that 
> you'll try the latest CFS version as soon as possible but that you were 
> busy with work. I sent 2 more emails to you about new CFS versions but 
> then stopped pestering you directly - work _does_ take precedence over 
> games =B-)
> 

I did respond to that one, but perhaps some mail have been getting lost,
cause i cant find any more from you in my inbox.

> CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went 
> upstream, there were no 3D related CFS regressions open for quite some 
> time and because i never heard back from you i assumed everything's 
> peachy.

I must admit i havent tested the very very latest, will do

> 
> In any case i'm glad you found the time to try CFS again, so please let 
> me know in what way it regresses. In your most recent emails you did not 
> indicate what specific problem you are having (and you did not reply to 
> my last emails from May) - are your old regression reports against CFS 
> v13 from May still true as of v2.6.23-rc1? If they are, could you please 
> indicate which specific report of yours describes it best and send me 
> (or upload to some webspace) the specific .config you are using on your 
> box, and the cfs-debug-info.sh snapshot taken when you are running your 
> game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest 
> quality debug output) You can pick the script up from:
> 
>   http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
> 
> Giving us that info would help us immensely with tracking down any CFS 
> problem you might still be having.

Sure.

> 
> Or, if you feel adventurous enough to look into the internals of the 
> kernel (which, considering your offer to take up SD maintenance, you 
> must be ;-), here's my kernel latency tracer:

Well, im not sure how good i would be at maintaining SD, my idea was
more or less just do the bare minimum to get the thing running on newer
kernels :)

> 
>    http://people.redhat.com/mingo/latency-tracing-patches/
> 
> ( see: latency-tracer-v2.6.23-rc1-combo.patch )
> 
> the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set 
> /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to 
> thus measure raw worst-case scheduler latencies - if you regularly see 
> the kernel report above say 1000 usecs latencies to the syslog, on a 
> PREEMPT kernel then there's definitely something foul going on. For 
> example, that's how i found an audio playback latency problem in an 
> early version of CFS:
> 
> (            sshd-14614|#1): new 5 us maximum-latency wakeup.
> (          ogg123-6603 |#1): new 6 us maximum-latency wakeup.
> (          ogg123-6608 |#1): new 6 us maximum-latency wakeup.
> (            sshd-14614|#1): new 10 us maximum-latency wakeup.
> (          ogg123-6607 |#0): new 15 us maximum-latency wakeup.
> (        events/0-9    |#0): new 789 us maximum-latency wakeup.
> (          ogg123-6603 |#0): new 2566 us maximum-latency wakeup.
> 

Actually, now that you mention ogg123, i've had some bugs on CFS with
this, i thought it was an ogg123 bug, but now that i remember it its
only on CFS i have it.. when i run multiple ogg123 instances, suddenly
they will just stop playing and lock up. This happens when someone
writes alot fast to me on kopete, where i use ogg123 to play a bling
sound..

> that 2.5 msecs latency in the ogg123 task was definitely the sign of a 
> kernel bug.
> 
> If plain WAKEUP_TIMING does not show anything suspicious, you can use 
> the latency tracer in more advanced ways as well to trace the whole 
> system and figure out the precise cause of your game latencies - i'll be 
> glad to help with that if no simpler measure helps. [see trace-it.c for 
> some of those details.]
> 
> > [...] As far as im concerned, i may be forced to unofficially maintain 
> > SD for my own systems(allthough lots in the gaming community is bound 
> > to be interrested, as it does make games lots better)
> 
> i'd encourage you to do it - in fact i already tried to prod Peter 
> Williams into doing exactly that ;) The more reality checks a scheduler 
> has, the better. [ Btw., after the obvious initial merging trouble it 
> should be much easier to keep SD maintained against future upstream 
> kernels due to the policy modularity that CFS introduces. (and which 
> policy-modularity should also help reduce the size and complexity of the 
> SD patch.) ]
> 
> Thanks,
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linus 2.6.23-rc1

[Ronni Nielsen]

Hmm

- Linus 2.6.23-rc1
+ Linux 2.6.23-rc1

Or are *you* now under versioning?
Or maybe a silent namechange of the kernel?

/ronni

Re: Linus 2.6.23-rc1

[Linus Torvalds]

On Sat, 28 Jul 2007, Ronni Nielsen wrote:
> 
> - Linus 2.6.23-rc1
> + Linux 2.6.23-rc1
> 
> Or are *you* now under versioning?
> Or maybe a silent namechange of the kernel?

Yeah, yeah, my fingers get confused. I type "Linux" and "Linus" 
interchangably, and _most_ of the time I notice, but then at other times I 
don't look closely enough at what I wrote, so something slips through. 

And sometimes when my right hand is off by a key, I'm Kubys.

My fingers have minds all their own.

			Linus

Re: Linus 2.6.23-rc1

[Volker Armin Hemmann]

Hi,

I never tried Con's patchset, for two reasons:
I tried his 2.4 patches ones, and I never saw any improvements. So when people 
were reporting huge improvements with his SD scheduler, I compared that with 
the reports of huge improvements with his 2.4 kernel patches.
...
The second: too many patches. I only would have tried one or two, but the 
ck-patchset is a lot bigger.. and I am a little bit uneasy about that.

But I tried a lot of Ingo's cfs patches - and it was a very pleasant 
experience. Ingo reacted very fast on my feedback and when I hit a problem he 
really tried to find the cause and solve it - and it always was one patch, so 
I felt a lot less scared ;)

My usual workload is very 'usual'. KDE desktop, kmail, konqueror, sometimes 
xine or amarok providing some background noise while typing away in kate, 
triplea, wesnoth or some other game when I need to 'rest' for a while. A lot 
of compiling in the background, because I am one of these gentoo users.

With cfs the experience was much more pleasant than with the 'old' scheduler. 
Compiling did not hurt as much as usual anymore - the only thing that hurts 
is swap.... 

But there is another thing I do regularly: I play ut2004. Not every single 
day, but sometimes several times a day. 20minutes of mayhem and then back to 
the desktop.

And I do not see any problems with cfs and ut2004. The maximum FPS are indeed 
a little bit lower (and you can argue that this really is not important if 
the pre-game FPS in a level looking down on the floor go down from 390 to 
380FPS), but the minimum FPS went up!

In scenes when my system is fighting hard to provide the FPS, when the action 
is high (like when fighting with half a douzend bots at a power node, while 
some other bots are shooting into the mess) CFS is much better than the old 
scheduler. It is a big difference if you get 6-10FPS or 15-25.
(I am playing with maximum 'beautifullness' - I would be able to get a lot 
more FPS, if I wanted, but I want a nice scenery and maximum visual 
effects ...)

>From my point of view 3D is a lot better with cfs. 

Now the question for all the people who are bashing cfs for its bad 3d 
performance: what am I doing wrong?

Glück Auf,
Volker

Re: Linus 2.6.23-rc1

[Kasper Sandberg]

On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote:
> Hi,
> 
> I never tried Con's patchset, for two reasons:
> I tried his 2.4 patches ones, and I never saw any improvements. So when people 
> were reporting huge improvements with his SD scheduler, I compared that with 
> the reports of huge improvements with his 2.4 kernel patches.

Well thats a reason if there ever were one...

> ...
> The second: too many patches. I only would have tried one or two, but the 
> ck-patchset is a lot bigger.. and I am a little bit uneasy about that.

so use only the scheduler? nobody forces you to do many things..

> 
> But I tried a lot of Ingo's cfs patches - and it was a very pleasant 
> experience. Ingo reacted very fast on my feedback and when I hit a problem he 
> really tried to find the cause and solve it - and it always was one patch, so 
> I felt a lot less scared ;)
> 
> My usual workload is very 'usual'. KDE desktop, kmail, konqueror, sometimes 
> xine or amarok providing some background noise while typing away in kate, 
> triplea, wesnoth or some other game when I need to 'rest' for a while. A lot 
> of compiling in the background, because I am one of these gentoo users.
> 
> With cfs the experience was much more pleasant than with the 'old' scheduler. 
> Compiling did not hurt as much as usual anymore - the only thing that hurts 
> is swap.... 
> 
> But there is another thing I do regularly: I play ut2004. Not every single 
> day, but sometimes several times a day. 20minutes of mayhem and then back to 
> the desktop.
> 
> And I do not see any problems with cfs and ut2004. The maximum FPS are indeed 
> a little bit lower (and you can argue that this really is not important if 
> the pre-game FPS in a level looking down on the floor go down from 390 to 
> 380FPS), but the minimum FPS went up!

well, surely CFS is better than the old vanilla scheduler, also with 3d,
and if you have that high fps, i doubt you will notice the effects me
and others are having. it is not that it is bad, its just not as good as
SD has shown to be possible..

> 
> In scenes when my system is fighting hard to provide the FPS, when the action 
> is high (like when fighting with half a douzend bots at a power node, while 
> some other bots are shooting into the mess) CFS is much better than the old 
> scheduler. It is a big difference if you get 6-10FPS or 15-25.
> (I am playing with maximum 'beautifullness' - I would be able to get a lot 
> more FPS, if I wanted, but I want a nice scenery and maximum visual 
> effects ...)
> 
> From my point of view 3D is a lot better with cfs. 

Better than old vanilla yes, but than SD? well, you should give it a
try.

> 
> Now the question for all the people who are bashing cfs for its bad 3d 
> performance: what am I doing wrong?

As said, we never said CFS was worse than old vanilla, and we never said
it was BAD, we did however say its not as good as SD :)

> 
> Glück Auf,
> Volker
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linus 2.6.23-rc1

[Volker Armin Hemmann]

On Sonntag, 29. Juli 2007, Kasper Sandberg wrote:
> On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote:
> > Hi,
> >
> > I never tried Con's patchset, for two reasons:
> > I tried his 2.4 patches ones, and I never saw any improvements. So when
> > people were reporting huge improvements with his SD scheduler, I compared
> > that with the reports of huge improvements with his 2.4 kernel patches.
>
> Well thats a reason if there ever were one...
>

yes, it is. The fans claimed once lots of stuff that was not true for me. So 
why believing them 'now'?

> > ...
> > The second: too many patches. I only would have tried one or two, but the
> > ck-patchset is a lot bigger.. and I am a little bit uneasy about that.
>
> so use only the scheduler? nobody forces you to do many things..

but which one is needed?
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.22/2.6.22-ck1/patches/

six patches who start with 'sched-' and which one is needed? and which is not? 
Can I only use sched-staircase-deadline-cpu-scheduler.patch  or do I need the 
others too?

> Better than old vanilla yes, but than SD? well, you should give it a
> try.
>

see above.