* [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
@ 2008-04-01 23:26 Cornelius Köpp
2008-04-02 3:01 ` Tomas Kalibera
2008-04-02 9:04 ` Jan Kiszka
0 siblings, 2 replies; 28+ messages in thread
From: Cornelius Köpp @ 2008-04-01 23:26 UTC (permalink / raw)
To: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
Hello,
I run the latency test from testsuite on several hard and software configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results shows a "strange" behavior: In Kernel mode (-t1) the latencys constantly linear decrease. See attached plot 'drifting_latencys_in_kernelmode.png' of latency test running 48h on Pentium3 700. This effect could be reproduced, even on other hardware (Pentium-M 1400). The usermode (-t0) did not show a drifting, but is influenced by a test ran in kernelmode before.
I talked with Sebastian Smolorz about this and he builds his own independent kernel-config to check. He got the same drifting-effect with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several hours. His kernel-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'.
Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects.
Bad luck with the config?
Thanks in advance,
Cornelius Köpp
[-- Attachment #2: drifting_latencys_in_kernelmode.png --]
[-- Type: image/png, Size: 26130 bytes --]
[-- Attachment #3: config.6.24-xenomai-2.4.2__ck --]
[-- Type: application/octet-stream, Size: 38945 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Feb 21 17:59:09 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=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_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_RWSEM_GENERIC_SPINLOCK is not set
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_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_SUPPORTS_OPROFILE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
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_PID_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
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_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=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_SLABINFO=y
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 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"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=512
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_XENO_HW_FPU=y
#
# NMI watchdog
#
#
# SMI workaround
#
# CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
CONFIG_XENO_HW_SMI_DETECT=y
CONFIG_XENO_HW_SMI_WORKAROUND=y
CONFIG_XENO_HW_SMI_ALL=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=m
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
# CONFIG_XENO_OPT_DEBUG_POSIX is not set
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
#
# Drivers
#
#
# Serial drivers
#
CONFIG_XENO_DRIVERS_16550A=m
CONFIG_XENO_DRIVERS_16550A_PIO=y
# CONFIG_XENO_DRIVERS_16550A_MMIO is not set
# CONFIG_XENO_DRIVERS_16550A_ANY is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
CONFIG_XENO_DRIVERS_IRQBENCH=m
CONFIG_XENO_DRIVERS_SWITCHTEST=m
#
# CAN drivers
#
CONFIG_XENO_DRIVERS_CAN=y
# CONFIG_XENO_DRIVERS_CAN_DEBUG is not set
# CONFIG_XENO_DRIVERS_CAN_LOOPBACK is not set
CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE=1024
CONFIG_XENO_DRIVERS_CAN_MAX_DEVICES=4
CONFIG_XENO_DRIVERS_CAN_MAX_RECEIVERS=16
CONFIG_XENO_DRIVERS_CAN_BUS_ERR=y
CONFIG_XENO_DRIVERS_CAN_VIRT=m
CONFIG_XENO_DRIVERS_CAN_SJA1000=y
CONFIG_XENO_DRIVERS_CAN_SJA1000_ISA=m
# CONFIG_XENO_DRIVERS_CAN_SJA1000_MEM is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_PCI is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_IXXAT_PCI is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_EMS_PCI is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_DNG is not set
#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
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_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_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_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
# CONFIG_HPET_TIMER is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_COMPAT=y
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=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_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
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 is not set
CONFIG_SECCOMP=y
# 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_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y
#
# Power management options
#
# CONFIG_PM is not set
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
#
# 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 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 is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_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
# 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=y
# 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_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
# CONFIG_PNP is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD 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 is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32000
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# 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_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# 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=y
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
#
# Other IDE chipsets support
#
#
# Note: most of these also require special kernel boot parameters
#
# CONFIG_BLK_DEV_4DRIVES is not set
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD65XX is not set
# CONFIG_BLK_DEV_UMC8672 is not set
# CONFIG_BLK_DEV_IDEDMA is not set
CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
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=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# 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 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_SRP_ATTRS 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 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=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# 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_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 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 is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
#
# Controllers
#
#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=m
#
# Protocols
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
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 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_SMC9194=m
# 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=m
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
# CONFIG_EWRK3 is not set
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 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_EEPRO100=m
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
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=m
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_VIA_RHINE_NAPI is not set
# CONFIG_SC92031 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IP1000 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 is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI 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 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=m
# CONFIG_INPUT_EVDEV is not set
# 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 is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
# CONFIG_JOYSTICK_IFORCE_232 is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD 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_WISTRON_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 is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_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_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI 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_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=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 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_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
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB 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 is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_VGASTATE=m
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
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_CFB_REV_PIXELS_IN_BYTE is not set
# 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 is not set
#
# 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=m
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# 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
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
#
# 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=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
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_ISD200 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=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
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_VIRTUALIZATION 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 is not set
# CONFIG_EXT2_FS_XIP 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=y
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=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS 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_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_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set
CONFIG_INSTRUMENTATION=y
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
# 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_IPIPE_DEBUG is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
CONFIG_FORCED_INLINING=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_HW 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_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
[-- Attachment #4: config-2.6.24-xenomai-2.4.3__ssm --]
[-- Type: application/octet-stream, Size: 39364 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Mon Mar 31 09:36:01 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=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_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_RWSEM_GENERIC_SPINLOCK is not set
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_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_SUPPORTS_OPROFILE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
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_PID_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
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_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=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_SLABINFO=y
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 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"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=512
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=32
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
CONFIG_XENO_OPT_SHIRQ=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_XENO_HW_FPU=y
#
# NMI watchdog
#
#
# SMI workaround
#
# CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
CONFIG_XENO_HW_SMI_DETECT=y
CONFIG_XENO_HW_SMI_WORKAROUND=y
CONFIG_XENO_HW_SMI_ALL=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
# CONFIG_XENO_OPT_DEBUG_NATIVE is not set
CONFIG_XENO_SKIN_POSIX=m
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
# CONFIG_XENO_OPT_POSIX_SELECT is not set
# CONFIG_XENO_OPT_DEBUG_POSIX is not set
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_OPT_RTDM_SELECT is not set
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
#
# Drivers
#
#
# Serial drivers
#
CONFIG_XENO_DRIVERS_16550A=m
CONFIG_XENO_DRIVERS_16550A_PIO=y
# CONFIG_XENO_DRIVERS_16550A_MMIO is not set
# CONFIG_XENO_DRIVERS_16550A_ANY is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
# CONFIG_XENO_DRIVERS_KLATENCY is not set
CONFIG_XENO_DRIVERS_IRQBENCH=m
CONFIG_XENO_DRIVERS_SWITCHTEST=m
#
# CAN drivers
#
CONFIG_XENO_DRIVERS_CAN=y
# CONFIG_XENO_DRIVERS_CAN_DEBUG is not set
# CONFIG_XENO_DRIVERS_CAN_LOOPBACK is not set
CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE=1024
CONFIG_XENO_DRIVERS_CAN_MAX_DEVICES=4
CONFIG_XENO_DRIVERS_CAN_MAX_RECEIVERS=16
CONFIG_XENO_DRIVERS_CAN_BUS_ERR=y
CONFIG_XENO_DRIVERS_CAN_VIRT=m
CONFIG_XENO_DRIVERS_CAN_SJA1000=y
# CONFIG_XENO_DRIVERS_CAN_SJA1000_ISA is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_MEM is not set
CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_PCI=m
# CONFIG_XENO_DRIVERS_CAN_SJA1000_IXXAT_PCI is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_EMS_PCI is not set
# CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_DNG is not set
#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
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_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_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_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
# CONFIG_HPET_TIMER is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_COMPAT=y
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=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_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
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 is not set
CONFIG_SECCOMP=y
# 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_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y
#
# Power management options
#
# CONFIG_PM is not set
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
#
# 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 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 is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_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
# 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=y
# 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_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
# CONFIG_PNP is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD 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 is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32000
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# 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_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# 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=y
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
#
# Other IDE chipsets support
#
#
# Note: most of these also require special kernel boot parameters
#
# CONFIG_BLK_DEV_4DRIVES is not set
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD65XX is not set
# CONFIG_BLK_DEV_UMC8672 is not set
# CONFIG_BLK_DEV_IDEDMA is not set
CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
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=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# 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 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_SRP_ATTRS 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 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=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# 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_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 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 is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
#
# Controllers
#
#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=m
#
# Protocols
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
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 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_SMC9194=m
# 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=m
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
# CONFIG_EWRK3 is not set
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 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_EEPRO100=m
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
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=m
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_VIA_RHINE_NAPI is not set
# CONFIG_SC92031 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 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=m
# CONFIG_INPUT_EVDEV is not set
# 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 is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
# CONFIG_JOYSTICK_IFORCE_232 is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD 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_WISTRON_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 is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_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_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI 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_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=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 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_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
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB 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 is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_VGASTATE=m
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
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_CFB_REV_PIXELS_IN_BYTE is not set
# 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 is not set
#
# 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=m
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# 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
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
#
# 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=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
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_ISD200 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=y
#
# USB port drivers
#
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=m
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG 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
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_VIRTUALIZATION 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 is not set
# CONFIG_EXT2_FS_XIP 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=y
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=y
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS 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_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_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set
# CONFIG_INSTRUMENTATION is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
# 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_IPIPE_DEBUG is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
CONFIG_FORCED_INLINING=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_HW 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_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-01 23:26 [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3) Cornelius Köpp
@ 2008-04-02 3:01 ` Tomas Kalibera
2008-04-02 9:04 ` Jan Kiszka
1 sibling, 0 replies; 28+ messages in thread
From: Tomas Kalibera @ 2008-04-02 3:01 UTC (permalink / raw)
To: Cornelius Köpp; +Cc: xenomai-core
Hi,
I don't have the answer, but just to feed my curiosity, do you know what
would happen if you run the benchmarks much longer ? I can imagine that
it would either stabilize on some value, or, it might start again from a
large value at the beginning..
Tomas
Cornelius Köpp wrote:
> Hello,
> I run the latency test from testsuite on several hard and software configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results shows a "strange" behavior: In Kernel mode (-t1) the latencys constantly linear decrease. See attached plot 'drifting_latencys_in_kernelmode.png' of latency test running 48h on Pentium3 700. This effect could be reproduced, even on other hardware (Pentium-M 1400). The usermode (-t0) did not show a drifting, but is influenced by a test ran in kernelmode before.
>
> I talked with Sebastian Smolorz about this and he builds his own independent kernel-config to check. He got the same drifting-effect with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several hours. His kernel-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'.
>
> Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects.
>
> Bad luck with the config?
>
>
> Thanks in advance,
>
> Cornelius Köpp
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-01 23:26 [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3) Cornelius Köpp
2008-04-02 3:01 ` Tomas Kalibera
@ 2008-04-02 9:04 ` Jan Kiszka
2008-04-02 12:00 ` Sebastian Smolorz
1 sibling, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-02 9:04 UTC (permalink / raw)
To: Cornelius Köpp; +Cc: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
Cornelius Köpp wrote:
> Hello,
> I run the latency test from testsuite on several hard and software configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results shows a "strange" behavior: In Kernel mode (-t1) the latencys constantly linear decrease. See attached plot 'drifting_latencys_in_kernelmode.png' of latency test running 48h on Pentium3 700. This effect could be reproduced, even on other hardware (Pentium-M 1400).
As our P3 boards did not support APIC-based timing (IIRC), your kernel
has correctly disabled the related kernel support. But the Pentium M
should be fine. So could you check if we are seeing some TSC clocks vs.
PIT timer rounding issue by enabling the local APIC on the Pentium M?
> The usermode (-t0) did not show a drifting, but is influenced by a test ran in kernelmode before.
What do you mean with "is influenced"?
>
> I talked with Sebastian Smolorz about this and he builds his own independent kernel-config to check. He got the same drifting-effect with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several hours. His kernel-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'.
>
> Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects.
2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is not
a PIC vs. APIC thing, but rather a rounding problem of larger TSC values
(that naturally show up when the system runs for a longer time).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 9:04 ` Jan Kiszka
@ 2008-04-02 12:00 ` Sebastian Smolorz
2008-04-02 12:28 ` Jan Kiszka
0 siblings, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-02 12:00 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
Jan Kiszka wrote:
> Cornelius Köpp wrote:
>> Hello,
>> I run the latency test from testsuite on several hard and software
>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
>> shows a "strange" behavior: In Kernel mode (-t1) the latencys
>> constantly linear decrease. See attached plot
>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on
>> Pentium3 700. This effect could be reproduced, even on other hardware
>> (Pentium-M 1400).
>
> As our P3 boards did not support APIC-based timing (IIRC), your kernel
> has correctly disabled the related kernel support. But the Pentium M
> should be fine. So could you check if we are seeing some TSC clocks vs.
> PIT timer rounding issue by enabling the local APIC on the Pentium M?
There is no difference in enabling the local APIC on the Pentium M WRT
this bug.
>> The usermode (-t0) did not show a drifting, but is influenced by a
>> test ran in kernelmode before.
>
> What do you mean with "is influenced"?
Cornelius saw the following behaviour: If the latency test was run in
user space first, no drift appeared over time. If latency was run in
kernel space (with the reported ngeative drift) a following latency test
in user space showed also negative values but with no additional drift
over time.
>> I talked with Sebastian Smolorz about this and he builds his own
>> independent kernel-config to check. He got the same drifting-effect
>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>> hours. His kernel-config ist attached as
>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>
>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
>> and Linux 2.6.20.15 without any drifting effects.
>
> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is not
> a PIC vs. APIC thing, but rather a rounding problem of larger TSC values
> (that naturally show up when the system runs for a longer time).
This hint seems to point into the right direction. I tried out a
modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
implementation in include/asm-generic/bits/pod.h was used. The drifting
bug disappeared. So there seems so be a buggy x86-specific
implementation of this routine.
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 12:00 ` Sebastian Smolorz
@ 2008-04-02 12:28 ` Jan Kiszka
2008-04-02 12:46 ` Gilles Chanteperdrix
2008-04-02 15:58 ` Sebastian Smolorz
0 siblings, 2 replies; 28+ messages in thread
From: Jan Kiszka @ 2008-04-02 12:28 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]
Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> Cornelius Köpp wrote:
>>> Hello,
>>> I run the latency test from testsuite on several hard and software
>>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
>>> shows a "strange" behavior: In Kernel mode (-t1) the latencys
>>> constantly linear decrease. See attached plot
>>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on
>>> Pentium3 700. This effect could be reproduced, even on other hardware
>>> (Pentium-M 1400).
>>
>> As our P3 boards did not support APIC-based timing (IIRC), your kernel
>> has correctly disabled the related kernel support. But the Pentium M
>> should be fine. So could you check if we are seeing some TSC clocks
>> vs. PIT timer rounding issue by enabling the local APIC on the Pentium M?
>
> There is no difference in enabling the local APIC on the Pentium M WRT
> this bug.
>
>>> The usermode (-t0) did not show a drifting, but is influenced by a
>>> test ran in kernelmode before.
>>
>> What do you mean with "is influenced"?
>
> Cornelius saw the following behaviour: If the latency test was run in
> user space first, no drift appeared over time. If latency was run in
> kernel space (with the reported ngeative drift) a following latency test
> in user space showed also negative values but with no additional drift
> over time.
>
>>> I talked with Sebastian Smolorz about this and he builds his own
>>> independent kernel-config to check. He got the same drifting-effect
>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>>> hours. His kernel-config ist attached as
>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>>
>>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
>>> and Linux 2.6.20.15 without any drifting effects.
>>
>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>> values (that naturally show up when the system runs for a longer time).
>
> This hint seems to point into the right direction. I tried out a
> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
> implementation in include/asm-generic/bits/pod.h was used. The drifting
> bug disappeared. So there seems so be a buggy x86-specific
> implementation of this routine.
Hmm, maybe even a conceptional issue: the multiply-shift-based
xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
may loose some bits, maybe too many bits...
It looks like this bites us in the kernel latency tests (-t2 should
suffer as well). Those recalculate their timeouts each round based on
absolute nanoseconds. In contrast, the periodic user mode task of -t0
uses a periodic timer that is forwarded via a tsc-based interval.
You (or Cornelius) could try to analyse the calculation path of the
involved timeouts, specifically to understand why the scheduled timeout
of the underlying task timer (which is tsc-based) tend to diverge from
the calculated one (ns-based).
TiA,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 12:28 ` Jan Kiszka
@ 2008-04-02 12:46 ` Gilles Chanteperdrix
2008-04-02 13:00 ` Sebastian Smolorz
2008-04-02 15:58 ` Sebastian Smolorz
1 sibling, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-02 12:46 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Sebastian Smolorz wrote:
> > Jan Kiszka wrote:
> >> Cornelius Köpp wrote:
> >>> Hello,
> >>> I run the latency test from testsuite on several hard and software
> >>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
> >>> shows a "strange" behavior: In Kernel mode (-t1) the latencys
> >>> constantly linear decrease. See attached plot
> >>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on
> >>> Pentium3 700. This effect could be reproduced, even on other hardware
> >>> (Pentium-M 1400).
> >>
> >> As our P3 boards did not support APIC-based timing (IIRC), your kernel
> >> has correctly disabled the related kernel support. But the Pentium M
> >> should be fine. So could you check if we are seeing some TSC clocks
> >> vs. PIT timer rounding issue by enabling the local APIC on the Pentium M?
> >
> > There is no difference in enabling the local APIC on the Pentium M WRT
> > this bug.
> >
> >>> The usermode (-t0) did not show a drifting, but is influenced by a
> >>> test ran in kernelmode before.
> >>
> >> What do you mean with "is influenced"?
> >
> > Cornelius saw the following behaviour: If the latency test was run in
> > user space first, no drift appeared over time. If latency was run in
> > kernel space (with the reported ngeative drift) a following latency test
> > in user space showed also negative values but with no additional drift
> > over time.
> >
> >>> I talked with Sebastian Smolorz about this and he builds his own
> >>> independent kernel-config to check. He got the same drifting-effect
> >>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
> >>> hours. His kernel-config ist attached as
> >>> 'config-2.6.24-xenomai-2.4.3__ssm'.
> >>>
> >>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
> >>> and Linux 2.6.20.15 without any drifting effects.
> >>
> >> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
> >> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
> >> values (that naturally show up when the system runs for a longer time).
> >
> > This hint seems to point into the right direction. I tried out a
> > modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
> > implementation in include/asm-generic/bits/pod.h was used. The drifting
> > bug disappeared. So there seems so be a buggy x86-specific
> > implementation of this routine.
>
> Hmm, maybe even a conceptional issue: the multiply-shift-based
> xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
> xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
> may loose some bits, maybe too many bits...
If you want to know whether llmulshft implementation is broken on x86
or if there is a design issue, you can attempt to use the generic
implementation on x86.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 12:46 ` Gilles Chanteperdrix
@ 2008-04-02 13:00 ` Sebastian Smolorz
2008-04-02 15:28 ` Sebastian Smolorz
0 siblings, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-02 13:00 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core, Cornelius Köpp
Gilles Chanteperdrix wrote:
> On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Sebastian Smolorz wrote:
>> > Jan Kiszka wrote:
>> >>
>> >> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>> >> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>> >> values (that naturally show up when the system runs for a longer time).
>> >
>> > This hint seems to point into the right direction. I tried out a
>> > modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>> > implementation in include/asm-generic/bits/pod.h was used. The drifting
>> > bug disappeared. So there seems so be a buggy x86-specific
>> > implementation of this routine.
>>
>> Hmm, maybe even a conceptional issue: the multiply-shift-based
>> xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
>> xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
>> may loose some bits, maybe too many bits...
>
> If you want to know whether llmulshft implementation is broken on x86
> or if there is a design issue, you can attempt to use the generic
> implementation on x86.
>
You mean not using rthal_llmulshft() in arith_32.h and instead using
__rthal_generic_llmulshft()? I tried this and it's also suffering from
the drift although it seems that the drift per time unit is smaller in
the generic case. I will try to get some numbers to compare the values
returned from rthal_llmulshft(), __rthal_generic_llmulshft() and
__rthal_generic_ullimd().
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 13:00 ` Sebastian Smolorz
@ 2008-04-02 15:28 ` Sebastian Smolorz
0 siblings, 0 replies; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-02 15:28 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core, Cornelius Köpp
Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
>> On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> Sebastian Smolorz wrote:
>>> > Jan Kiszka wrote:
>>> >>
>>> >> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>>> >> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>>> >> values (that naturally show up when the system runs for a longer time).
>>> >
>>> > This hint seems to point into the right direction. I tried out a
>>> > modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>>> > implementation in include/asm-generic/bits/pod.h was used. The drifting
>>> > bug disappeared. So there seems so be a buggy x86-specific
>>> > implementation of this routine.
>>>
>>> Hmm, maybe even a conceptional issue: the multiply-shift-based
>>> xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
>>> xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
>>> may loose some bits, maybe too many bits...
>> If you want to know whether llmulshft implementation is broken on x86
>> or if there is a design issue, you can attempt to use the generic
>> implementation on x86.
>>
>
> You mean not using rthal_llmulshft() in arith_32.h and instead using
> __rthal_generic_llmulshft()? I tried this and it's also suffering from
> the drift although it seems that the drift per time unit is smaller in
> the generic case.
This was a subjective impression, the drift caused by rthal_llmulshft()
and __rthal_generic_llmulshft() is the same.
> I will try to get some numbers to compare the values
> returned from rthal_llmulshft(), __rthal_generic_llmulshft() and
> __rthal_generic_ullimd().
>
Here are some results. The latency test run one hour and 46 minutes
(kernel mode). I measured the difference between the return value of the
routine __rthal_generic_ullimd() which I considered as right and the
return value of rthal_llmulshft(). This difference increases over time.
At start: 21 ns
After 1 minute: 50 ns
After 4 minutes: 132 ns
After 8 minutes: 238 ns
After 86 minutes: 2342 ns
The higher the TSC value the bigger the error during the conversion of
the TSC value to nanoseconds. The converted value is too small. This all
explains why latency reports decreasing values over time.
Houston, we have a problem.
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 12:28 ` Jan Kiszka
2008-04-02 12:46 ` Gilles Chanteperdrix
@ 2008-04-02 15:58 ` Sebastian Smolorz
2008-04-02 16:05 ` Gilles Chanteperdrix
1 sibling, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-02 15:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
Jan Kiszka wrote:
> Sebastian Smolorz wrote:
>> Jan Kiszka wrote:
>>> Cornelius Köpp wrote:
>>>> Hello,
>>>> I run the latency test from testsuite on several hard and software
>>>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
>>>> shows a "strange" behavior: In Kernel mode (-t1) the latencys
>>>> constantly linear decrease. See attached plot
>>>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on
>>>> Pentium3 700. This effect could be reproduced, even on other hardware
>>>> (Pentium-M 1400).
>>> As our P3 boards did not support APIC-based timing (IIRC), your kernel
>>> has correctly disabled the related kernel support. But the Pentium M
>>> should be fine. So could you check if we are seeing some TSC clocks
>>> vs. PIT timer rounding issue by enabling the local APIC on the Pentium M?
>> There is no difference in enabling the local APIC on the Pentium M WRT
>> this bug.
>>
>>>> The usermode (-t0) did not show a drifting, but is influenced by a
>>>> test ran in kernelmode before.
>>> What do you mean with "is influenced"?
>> Cornelius saw the following behaviour: If the latency test was run in
>> user space first, no drift appeared over time. If latency was run in
>> kernel space (with the reported ngeative drift) a following latency test
>> in user space showed also negative values but with no additional drift
>> over time.
Correction: The initial negative drift when starting user mode latency
does not depend on a former run of latency in kernel mode but on the
time passed between system start and the starting point of latency -t0.
Or, as explained below, it depends on the value of the TSC.
>>
>>>> I talked with Sebastian Smolorz about this and he builds his own
>>>> independent kernel-config to check. He got the same drifting-effect
>>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>>>> hours. His kernel-config ist attached as
>>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>>>
>>>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
>>>> and Linux 2.6.20.15 without any drifting effects.
>>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>>> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>>> values (that naturally show up when the system runs for a longer time).
>> This hint seems to point into the right direction. I tried out a
>> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>> implementation in include/asm-generic/bits/pod.h was used. The drifting
>> bug disappeared. So there seems so be a buggy x86-specific
>> implementation of this routine.
>
> Hmm, maybe even a conceptional issue: the multiply-shift-based
> xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
> xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
> may loose some bits, maybe too many bits...
>
> It looks like this bites us in the kernel latency tests (-t2 should
> suffer as well). Those recalculate their timeouts each round based on
> absolute nanoseconds. In contrast, the periodic user mode task of -t0
> uses a periodic timer that is forwarded via a tsc-based interval.
>
> You (or Cornelius) could try to analyse the calculation path of the
> involved timeouts, specifically to understand why the scheduled timeout
> of the underlying task timer (which is tsc-based) tend to diverge from
> the calculated one (ns-based).
So here comes the explanation. The error is inside the function
rthal_llmulshft(). It returns wrong values which are too small - the
higher the given TSC value the bigger the error. The function
rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
rtdm_clock_read_monotonic() is called every time the latency kernel
thread runs [1] the values reported by latency become smaller over time.
In contrast, the latency task in user space only uses the conversion
from TSC to ns only once when calling rt_timer_inquire [2].
timer_info.date is too small, timer_info.tsc is right. So all calculated
deltas in [3] are shifted to a smaller value. This value is constant
during the runtime of lateny in user space because no more conversion
from TSC to ns occurs.
[1]
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/timerbench.c#166
[2]
http://www.rts.uni-hannover.de/xenomai/lxr/source/src/testsuite/latency/latency.c#076
[3]
http://www.rts.uni-hannover.de/xenomai/lxr/source/src/testsuite/latency/latency.c#111
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 15:58 ` Sebastian Smolorz
@ 2008-04-02 16:05 ` Gilles Chanteperdrix
2008-04-02 16:24 ` Sebastian Smolorz
0 siblings, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-02 16:05 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: Jan Kiszka, xenomai-core, Cornelius Köpp
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
<smolorz@domain.hid> wrote:
>
> Jan Kiszka wrote:
> > Sebastian Smolorz wrote:
> >> Jan Kiszka wrote:
> >>> Cornelius Köpp wrote:
> >>>> Hello,
> >>>> I run the latency test from testsuite on several hard and software
> >>>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
> >>>> shows a "strange" behavior: In Kernel mode (-t1) the latencys
> >>>> constantly linear decrease. See attached plot
> >>>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on
> >>>> Pentium3 700. This effect could be reproduced, even on other hardware
> >>>> (Pentium-M 1400).
> >>> As our P3 boards did not support APIC-based timing (IIRC), your kernel
> >>> has correctly disabled the related kernel support. But the Pentium M
> >>> should be fine. So could you check if we are seeing some TSC clocks
> >>> vs. PIT timer rounding issue by enabling the local APIC on the Pentium M?
> >> There is no difference in enabling the local APIC on the Pentium M WRT
> >> this bug.
> >>
> >>>> The usermode (-t0) did not show a drifting, but is influenced by a
> >>>> test ran in kernelmode before.
> >>> What do you mean with "is influenced"?
> >> Cornelius saw the following behaviour: If the latency test was run in
> >> user space first, no drift appeared over time. If latency was run in
> >> kernel space (with the reported ngeative drift) a following latency test
> >> in user space showed also negative values but with no additional drift
> >> over time.
>
> Correction: The initial negative drift when starting user mode latency
> does not depend on a former run of latency in kernel mode but on the
> time passed between system start and the starting point of latency -t0.
> Or, as explained below, it depends on the value of the TSC.
>
>
>
> >>
> >>>> I talked with Sebastian Smolorz about this and he builds his own
> >>>> independent kernel-config to check. He got the same drifting-effect
> >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
> >>>> hours. His kernel-config ist attached as
> >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
> >>>>
> >>>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
> >>>> and Linux 2.6.20.15 without any drifting effects.
> >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
> >>> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
> >>> values (that naturally show up when the system runs for a longer time).
> >> This hint seems to point into the right direction. I tried out a
> >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
> >> implementation in include/asm-generic/bits/pod.h was used. The drifting
> >> bug disappeared. So there seems so be a buggy x86-specific
> >> implementation of this routine.
> >
> > Hmm, maybe even a conceptional issue: the multiply-shift-based
> > xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
> > xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
> > may loose some bits, maybe too many bits...
> >
> > It looks like this bites us in the kernel latency tests (-t2 should
> > suffer as well). Those recalculate their timeouts each round based on
> > absolute nanoseconds. In contrast, the periodic user mode task of -t0
> > uses a periodic timer that is forwarded via a tsc-based interval.
> >
> > You (or Cornelius) could try to analyse the calculation path of the
> > involved timeouts, specifically to understand why the scheduled timeout
> > of the underlying task timer (which is tsc-based) tend to diverge from
> > the calculated one (ns-based).
>
> So here comes the explanation. The error is inside the function
> rthal_llmulshft(). It returns wrong values which are too small - the
> higher the given TSC value the bigger the error. The function
> rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
> rtdm_clock_read_monotonic() is called every time the latency kernel
> thread runs [1] the values reported by latency become smaller over time.
>
> In contrast, the latency task in user space only uses the conversion
> from TSC to ns only once when calling rt_timer_inquire [2].
> timer_info.date is too small, timer_info.tsc is right. So all calculated
> deltas in [3] are shifted to a smaller value. This value is constant
> during the runtime of lateny in user space because no more conversion
> from TSC to ns occurs.
latency does conversions from tsc to ns, but it converts time
differences, so the error is small relative to the results. In
contrast, doing substractions of conversion results is wrong. In other
words, doing:
start = rt_timer_tsc();
stop = rt_timer_tsc();
diffns = rt_timer_tsc2ns(stop - start);
is right. Whereas doing:
start = rt_timer_tsc2ns(rt_timer_tsc());
stop = rt_timer_tsc2ns(rt_timer_tsc());
diffns = stop - start;
is wrong.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 16:05 ` Gilles Chanteperdrix
@ 2008-04-02 16:24 ` Sebastian Smolorz
2008-04-03 12:17 ` Jan Kiszka
0 siblings, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-02 16:24 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core, Cornelius Köpp
Gilles Chanteperdrix wrote:
> On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
> <smolorz@domain.hid> wrote:
>> Jan Kiszka wrote:
>> > Sebastian Smolorz wrote:
>> >> Jan Kiszka wrote:
>> >>> Cornelius Köpp wrote:
>> >>>> I talked with Sebastian Smolorz about this and he builds his own
>> >>>> independent kernel-config to check. He got the same drifting-effect
>> >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>> >>>> hours. His kernel-config ist attached as
>> >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>> >>>>
>> >>>> Our kernel-configs are both based on a config used with Xenomai 2.3.4
>> >>>> and Linux 2.6.20.15 without any drifting effects.
>> >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>> >>> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>> >>> values (that naturally show up when the system runs for a longer time).
>> >> This hint seems to point into the right direction. I tried out a
>> >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>> >> implementation in include/asm-generic/bits/pod.h was used. The drifting
>> >> bug disappeared. So there seems so be a buggy x86-specific
>> >> implementation of this routine.
>> >
>> > Hmm, maybe even a conceptional issue: the multiply-shift-based
>> > xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
>> > xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
>> > may loose some bits, maybe too many bits...
>> >
>> > It looks like this bites us in the kernel latency tests (-t2 should
>> > suffer as well). Those recalculate their timeouts each round based on
>> > absolute nanoseconds. In contrast, the periodic user mode task of -t0
>> > uses a periodic timer that is forwarded via a tsc-based interval.
>> >
>> > You (or Cornelius) could try to analyse the calculation path of the
>> > involved timeouts, specifically to understand why the scheduled timeout
>> > of the underlying task timer (which is tsc-based) tend to diverge from
>> > the calculated one (ns-based).
>>
>> So here comes the explanation. The error is inside the function
>> rthal_llmulshft(). It returns wrong values which are too small - the
>> higher the given TSC value the bigger the error. The function
>> rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
>> rtdm_clock_read_monotonic() is called every time the latency kernel
>> thread runs [1] the values reported by latency become smaller over time.
>>
>> In contrast, the latency task in user space only uses the conversion
>> from TSC to ns only once when calling rt_timer_inquire [2].
>> timer_info.date is too small, timer_info.tsc is right. So all calculated
>> deltas in [3] are shifted to a smaller value. This value is constant
>> during the runtime of lateny in user space because no more conversion
>> from TSC to ns occurs.
>
> latency does conversions from tsc to ns, but it converts time
> differences, so the error is small relative to the results.
Of course. I wasn't precise with my last statement. It should be: No
more conversions from *absolute* TSC values to ns occur.
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-02 16:24 ` Sebastian Smolorz
@ 2008-04-03 12:17 ` Jan Kiszka
2008-04-03 12:27 ` Gilles Chanteperdrix
2008-04-03 13:15 ` Sebastian Smolorz
0 siblings, 2 replies; 28+ messages in thread
From: Jan Kiszka @ 2008-04-03 12:17 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1.1: Type: text/plain, Size: 3909 bytes --]
Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
>> On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
>> <smolorz@domain.hid> wrote:
>>> Jan Kiszka wrote:
>>> > Sebastian Smolorz wrote:
>>> >> Jan Kiszka wrote:
>>> >>> Cornelius Köpp wrote:
>>> >>>> I talked with Sebastian Smolorz about this and he builds his own
>>> >>>> independent kernel-config to check. He got the same
>>> drifting-effect
>>> >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>>> >>>> hours. His kernel-config ist attached as
>>> >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>> >>>>
>>> >>>> Our kernel-configs are both based on a config used with Xenomai
>>> 2.3.4
>>> >>>> and Linux 2.6.20.15 without any drifting effects.
>>> >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>>> >>> not a PIC vs. APIC thing, but rather a rounding problem of
>>> larger TSC
>>> >>> values (that naturally show up when the system runs for a longer
>>> time).
>>> >> This hint seems to point into the right direction. I tried out a
>>> >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>>> >> implementation in include/asm-generic/bits/pod.h was used. The
>>> drifting
>>> >> bug disappeared. So there seems so be a buggy x86-specific
>>> >> implementation of this routine.
>>> >
>>> > Hmm, maybe even a conceptional issue: the multiply-shift-based
>>> > xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
>>> > xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
>>> > may loose some bits, maybe too many bits...
>>> >
>>> > It looks like this bites us in the kernel latency tests (-t2 should
>>> > suffer as well). Those recalculate their timeouts each round based on
>>> > absolute nanoseconds. In contrast, the periodic user mode task of -t0
>>> > uses a periodic timer that is forwarded via a tsc-based interval.
>>> >
>>> > You (or Cornelius) could try to analyse the calculation path of the
>>> > involved timeouts, specifically to understand why the scheduled
>>> timeout
>>> > of the underlying task timer (which is tsc-based) tend to diverge
>>> from
>>> > the calculated one (ns-based).
>>>
>>> So here comes the explanation. The error is inside the function
>>> rthal_llmulshft(). It returns wrong values which are too small - the
>>> higher the given TSC value the bigger the error. The function
>>> rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
>>> rtdm_clock_read_monotonic() is called every time the latency kernel
>>> thread runs [1] the values reported by latency become smaller over
>>> time.
>>>
>>> In contrast, the latency task in user space only uses the conversion
>>> from TSC to ns only once when calling rt_timer_inquire [2].
>>> timer_info.date is too small, timer_info.tsc is right. So all
>>> calculated
>>> deltas in [3] are shifted to a smaller value. This value is constant
>>> during the runtime of lateny in user space because no more conversion
>>> from TSC to ns occurs.
>>
>> latency does conversions from tsc to ns, but it converts time
>> differences, so the error is small relative to the results.
>
> Of course. I wasn't precise with my last statement. It should be: No
> more conversions from *absolute* TSC values to ns occur.
>
This patch may do the trick: it uses the inverted tsc-to-ns function
instead of the frequency-based one. Be warned, it is totally untested
inside Xenomai, I just ran it in a user space test program. But it may
give an idea.
Gilles, not sure if this is related to my quickly hacked test, but with
RTHAL_CPU_FREQ = 800MHz and TSC = 0x7000000000000000 (or larger) I get
an arithmetic exception with the rthal_llimd-based conversion to
nanoseconds. Is there an input range we may have to exclude for rthal_llimd?
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fixup-scaled-ns2tsc-conversion.patch --]
[-- Type: text/x-patch; name="fixup-scaled-ns2tsc-conversion.patch", Size: 2969 bytes --]
---
include/asm-x86/bits/init_32.h | 3 ++-
include/asm-x86/bits/init_64.h | 3 ++-
include/asm-x86/bits/pod_32.h | 7 +++++++
include/asm-x86/bits/pod_64.h | 7 +++++++
4 files changed, 18 insertions(+), 2 deletions(-)
Index: b/include/asm-x86/bits/init_32.h
===================================================================
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -73,7 +73,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -89,6 +89,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/init_64.h
===================================================================
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -70,7 +70,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -86,6 +86,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/pod_32.h
===================================================================
--- a/include/asm-x86/bits/pod_32.h
+++ b/include/asm-x86/bits/pod_32.h
@@ -25,6 +25,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -32,6 +33,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ts, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
Index: b/include/asm-x86/bits/pod_64.h
===================================================================
--- a/include/asm-x86/bits/pod_64.h
+++ b/include/asm-x86/bits/pod_64.h
@@ -24,6 +24,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -31,6 +32,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ts, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 12:17 ` Jan Kiszka
@ 2008-04-03 12:27 ` Gilles Chanteperdrix
2008-04-03 12:50 ` Jan Kiszka
2008-04-03 13:15 ` Sebastian Smolorz
1 sibling, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-03 12:27 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Thu, Apr 3, 2008 at 2:17 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Sebastian Smolorz wrote:
>
> > Gilles Chanteperdrix wrote:
> >
> > > On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
> > > <smolorz@domain.hid> wrote:
> > >
> > > > Jan Kiszka wrote:
> > > > > Sebastian Smolorz wrote:
> > > > >> Jan Kiszka wrote:
> > > > >>> Cornelius Köpp wrote:
> > > > >>>> I talked with Sebastian Smolorz about this and he builds his own
> > > > >>>> independent kernel-config to check. He got the same
> drifting-effect
> > > > >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over
> several
> > > > >>>> hours. His kernel-config ist attached as
> > > > >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
> > > > >>>>
> > > > >>>> Our kernel-configs are both based on a config used with Xenomai
> 2.3.4
> > > > >>>> and Linux 2.6.20.15 without any drifting effects.
> > > > >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it
> is
> > > > >>> not a PIC vs. APIC thing, but rather a rounding problem of larger
> TSC
> > > > >>> values (that naturally show up when the system runs for a longer
> time).
> > > > >> This hint seems to point into the right direction. I tried out a
> > > > >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the
> old
> > > > >> implementation in include/asm-generic/bits/pod.h was used. The
> drifting
> > > > >> bug disappeared. So there seems so be a buggy x86-specific
> > > > >> implementation of this routine.
> > > > >
> > > > > Hmm, maybe even a conceptional issue: the multiply-shift-based
> > > > > xnarch_tsc_to_ns is not as precise as the still
> multiply-divide-based
> > > > > xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc,
> we
> > > > > may loose some bits, maybe too many bits...
> > > > >
> > > > > It looks like this bites us in the kernel latency tests (-t2 should
> > > > > suffer as well). Those recalculate their timeouts each round based
> on
> > > > > absolute nanoseconds. In contrast, the periodic user mode task of
> -t0
> > > > > uses a periodic timer that is forwarded via a tsc-based interval.
> > > > >
> > > > > You (or Cornelius) could try to analyse the calculation path of the
> > > > > involved timeouts, specifically to understand why the scheduled
> timeout
> > > > > of the underlying task timer (which is tsc-based) tend to diverge
> from
> > > > > the calculated one (ns-based).
> > > >
> > > > So here comes the explanation. The error is inside the function
> > > > rthal_llmulshft(). It returns wrong values which are too small - the
> > > > higher the given TSC value the bigger the error. The function
> > > > rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
> > > > rtdm_clock_read_monotonic() is called every time the latency kernel
> > > > thread runs [1] the values reported by latency become smaller over
> time.
> > > >
> > > > In contrast, the latency task in user space only uses the conversion
> > > > from TSC to ns only once when calling rt_timer_inquire [2].
> > > > timer_info.date is too small, timer_info.tsc is right. So all
> calculated
> > > > deltas in [3] are shifted to a smaller value. This value is constant
> > > > during the runtime of lateny in user space because no more conversion
> > > > from TSC to ns occurs.
> > > >
> > >
> > > latency does conversions from tsc to ns, but it converts time
> > > differences, so the error is small relative to the results.
> > >
> >
> > Of course. I wasn't precise with my last statement. It should be: No more
> conversions from *absolute* TSC values to ns occur.
> >
> >
>
> This patch may do the trick: it uses the inverted tsc-to-ns function
> instead of the frequency-based one. Be warned, it is totally untested inside
> Xenomai, I just ran it in a user space test program. But it may give an
> idea.
>
> Gilles, not sure if this is related to my quickly hacked test, but with
> RTHAL_CPU_FREQ = 800MHz and TSC = 0x7000000000000000 (or larger) I get an
> arithmetic exception with the rthal_llimd-based conversion to nanoseconds.
> Is there an input range we may have to exclude for rthal_llimd?
rthal_llimd does a multiplication first, then a division. The
multiplication can not overflow, but the result of the division may
not fit on 64 bits, you then get an exception on x86. This happens
only with m > d.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 12:27 ` Gilles Chanteperdrix
@ 2008-04-03 12:50 ` Jan Kiszka
2008-04-03 12:52 ` Gilles Chanteperdrix
0 siblings, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-03 12:50 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 4877 bytes --]
Gilles Chanteperdrix wrote:
> On Thu, Apr 3, 2008 at 2:17 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Sebastian Smolorz wrote:
>>
>>> Gilles Chanteperdrix wrote:
>>>
>>>> On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
>>>> <smolorz@domain.hid> wrote:
>>>>
>>>>> Jan Kiszka wrote:
>>>>> > Sebastian Smolorz wrote:
>>>>> >> Jan Kiszka wrote:
>>>>> >>> Cornelius Köpp wrote:
>>>>> >>>> I talked with Sebastian Smolorz about this and he builds his own
>>>>> >>>> independent kernel-config to check. He got the same
>> drifting-effect
>>>>> >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over
>> several
>>>>> >>>> hours. His kernel-config ist attached as
>>>>> >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>>>> >>>>
>>>>> >>>> Our kernel-configs are both based on a config used with Xenomai
>> 2.3.4
>>>>> >>>> and Linux 2.6.20.15 without any drifting effects.
>>>>> >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it
>> is
>>>>> >>> not a PIC vs. APIC thing, but rather a rounding problem of larger
>> TSC
>>>>> >>> values (that naturally show up when the system runs for a longer
>> time).
>>>>> >> This hint seems to point into the right direction. I tried out a
>>>>> >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the
>> old
>>>>> >> implementation in include/asm-generic/bits/pod.h was used. The
>> drifting
>>>>> >> bug disappeared. So there seems so be a buggy x86-specific
>>>>> >> implementation of this routine.
>>>>> >
>>>>> > Hmm, maybe even a conceptional issue: the multiply-shift-based
>>>>> > xnarch_tsc_to_ns is not as precise as the still
>> multiply-divide-based
>>>>> > xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc,
>> we
>>>>> > may loose some bits, maybe too many bits...
>>>>> >
>>>>> > It looks like this bites us in the kernel latency tests (-t2 should
>>>>> > suffer as well). Those recalculate their timeouts each round based
>> on
>>>>> > absolute nanoseconds. In contrast, the periodic user mode task of
>> -t0
>>>>> > uses a periodic timer that is forwarded via a tsc-based interval.
>>>>> >
>>>>> > You (or Cornelius) could try to analyse the calculation path of the
>>>>> > involved timeouts, specifically to understand why the scheduled
>> timeout
>>>>> > of the underlying task timer (which is tsc-based) tend to diverge
>> from
>>>>> > the calculated one (ns-based).
>>>>>
>>>>> So here comes the explanation. The error is inside the function
>>>>> rthal_llmulshft(). It returns wrong values which are too small - the
>>>>> higher the given TSC value the bigger the error. The function
>>>>> rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
>>>>> rtdm_clock_read_monotonic() is called every time the latency kernel
>>>>> thread runs [1] the values reported by latency become smaller over
>> time.
>>>>> In contrast, the latency task in user space only uses the conversion
>>>>> from TSC to ns only once when calling rt_timer_inquire [2].
>>>>> timer_info.date is too small, timer_info.tsc is right. So all
>> calculated
>>>>> deltas in [3] are shifted to a smaller value. This value is constant
>>>>> during the runtime of lateny in user space because no more conversion
>>>>> from TSC to ns occurs.
>>>>>
>>>> latency does conversions from tsc to ns, but it converts time
>>>> differences, so the error is small relative to the results.
>>>>
>>> Of course. I wasn't precise with my last statement. It should be: No more
>> conversions from *absolute* TSC values to ns occur.
>>>
>> This patch may do the trick: it uses the inverted tsc-to-ns function
>> instead of the frequency-based one. Be warned, it is totally untested inside
>> Xenomai, I just ran it in a user space test program. But it may give an
>> idea.
>>
>> Gilles, not sure if this is related to my quickly hacked test, but with
>> RTHAL_CPU_FREQ = 800MHz and TSC = 0x7000000000000000 (or larger) I get an
>> arithmetic exception with the rthal_llimd-based conversion to nanoseconds.
>> Is there an input range we may have to exclude for rthal_llimd?
>
> rthal_llimd does a multiplication first, then a division. The
> multiplication can not overflow, but the result of the division may
> not fit on 64 bits, you then get an exception on x86. This happens
> only with m > d.
OK, for tsc-to-ns this only bites us after a few hundred years of uptime
- or when we have settable tsc counters (does Linux tweak them beyond
aligning on SMP?).
But there is also the risk the other way around: ns-to-tsc with
frequency > 1GHz will fall apart (kernel oops!) when the user provides a
large timeout in nanoseconds that we then try to convert to tsc. Not
good. Wrong values are one thing, but oopses are even worse.
Any idea how to fix this?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 12:50 ` Jan Kiszka
@ 2008-04-03 12:52 ` Gilles Chanteperdrix
0 siblings, 0 replies; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-03 12:52 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Thu, Apr 3, 2008 at 2:50 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
>
> > On Thu, Apr 3, 2008 at 2:17 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >
> > > Sebastian Smolorz wrote:
> > >
> > >
> > > > Gilles Chanteperdrix wrote:
> > > >
> > > >
> > > > > On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
> > > > > <smolorz@domain.hid> wrote:
> > > > >
> > > > >
> > > > > > Jan Kiszka wrote:
> > > > > > > Sebastian Smolorz wrote:
> > > > > > >> Jan Kiszka wrote:
> > > > > > >>> Cornelius Köpp wrote:
> > > > > > >>>> I talked with Sebastian Smolorz about this and he builds his
> own
> > > > > > >>>> independent kernel-config to check. He got the same
> > > > > >
> > > > >
> > > >
> > > drifting-effect
> > >
> > > >
> > > > >
> > > > > > >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over
> > > > > >
> > > > >
> > > >
> > > several
> > >
> > > >
> > > > >
> > > > > > >>>> hours. His kernel-config ist attached as
> > > > > > >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
> > > > > > >>>>
> > > > > > >>>> Our kernel-configs are both based on a config used with
> Xenomai
> > > > > >
> > > > >
> > > >
> > > 2.3.4
> > >
> > > >
> > > > >
> > > > > > >>>> and Linux 2.6.20.15 without any drifting effects.
> > > > > > >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe
> it
> > > > > >
> > > > >
> > > >
> > > is
> > >
> > > >
> > > > >
> > > > > > >>> not a PIC vs. APIC thing, but rather a rounding problem of
> larger
> > > > > >
> > > > >
> > > >
> > > TSC
> > >
> > > >
> > > > >
> > > > > > >>> values (that naturally show up when the system runs for a
> longer
> > > > > >
> > > > >
> > > >
> > > time).
> > >
> > > >
> > > > >
> > > > > > >> This hint seems to point into the right direction. I tried out
> a
> > > > > > >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that
> the
> > > > > >
> > > > >
> > > >
> > > old
> > >
> > > >
> > > > >
> > > > > > >> implementation in include/asm-generic/bits/pod.h was used. The
> > > > > >
> > > > >
> > > >
> > > drifting
> > >
> > > >
> > > > >
> > > > > > >> bug disappeared. So there seems so be a buggy x86-specific
> > > > > > >> implementation of this routine.
> > > > > > >
> > > > > > > Hmm, maybe even a conceptional issue: the multiply-shift-based
> > > > > > > xnarch_tsc_to_ns is not as precise as the still
> > > > > >
> > > > >
> > > >
> > > multiply-divide-based
> > >
> > > >
> > > > >
> > > > > > > xnarch_ns_to_tsc. So when converting from tsc over ns back to
> tsc,
> > > > > >
> > > > >
> > > >
> > > we
> > >
> > > >
> > > > >
> > > > > > > may loose some bits, maybe too many bits...
> > > > > > >
> > > > > > > It looks like this bites us in the kernel latency tests (-t2
> should
> > > > > > > suffer as well). Those recalculate their timeouts each round
> based
> > > > > >
> > > > >
> > > >
> > > on
> > >
> > > >
> > > > >
> > > > > > > absolute nanoseconds. In contrast, the periodic user mode task
> of
> > > > > >
> > > > >
> > > >
> > > -t0
> > >
> > > >
> > > > >
> > > > > > > uses a periodic timer that is forwarded via a tsc-based
> interval.
> > > > > > >
> > > > > > > You (or Cornelius) could try to analyse the calculation path of
> the
> > > > > > > involved timeouts, specifically to understand why the scheduled
> > > > > >
> > > > >
> > > >
> > > timeout
> > >
> > > >
> > > > >
> > > > > > > of the underlying task timer (which is tsc-based) tend to
> diverge
> > > > > >
> > > > >
> > > >
> > > from
> > >
> > > >
> > > > >
> > > > > > > the calculated one (ns-based).
> > > > > >
> > > > > > So here comes the explanation. The error is inside the function
> > > > > > rthal_llmulshft(). It returns wrong values which are too small -
> the
> > > > > > higher the given TSC value the bigger the error. The function
> > > > > > rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
> > > > > > rtdm_clock_read_monotonic() is called every time the latency
> kernel
> > > > > > thread runs [1] the values reported by latency become smaller
> over
> > > > > >
> > > > >
> > > >
> > > time.
> > >
> > > >
> > > > >
> > > > > > In contrast, the latency task in user space only uses the
> conversion
> > > > > > from TSC to ns only once when calling rt_timer_inquire [2].
> > > > > > timer_info.date is too small, timer_info.tsc is right. So all
> > > > > >
> > > > >
> > > >
> > > calculated
> > >
> > > >
> > > > >
> > > > > > deltas in [3] are shifted to a smaller value. This value is
> constant
> > > > > > during the runtime of lateny in user space because no more
> conversion
> > > > > > from TSC to ns occurs.
> > > > > >
> > > > > >
> > > > > latency does conversions from tsc to ns, but it converts time
> > > > > differences, so the error is small relative to the results.
> > > > >
> > > > >
> > > > Of course. I wasn't precise with my last statement. It should be: No
> more
> > > >
> > > conversions from *absolute* TSC values to ns occur.
> > >
> > > >
> > > >
> > > This patch may do the trick: it uses the inverted tsc-to-ns function
> > > instead of the frequency-based one. Be warned, it is totally untested
> inside
> > > Xenomai, I just ran it in a user space test program. But it may give an
> > > idea.
> > >
> > > Gilles, not sure if this is related to my quickly hacked test, but with
> > > RTHAL_CPU_FREQ = 800MHz and TSC = 0x7000000000000000 (or larger) I get
> an
> > > arithmetic exception with the rthal_llimd-based conversion to
> nanoseconds.
> > > Is there an input range we may have to exclude for rthal_llimd?
> > >
> >
> > rthal_llimd does a multiplication first, then a division. The
> > multiplication can not overflow, but the result of the division may
> > not fit on 64 bits, you then get an exception on x86. This happens
> > only with m > d.
> >
>
> OK, for tsc-to-ns this only bites us after a few hundred years of uptime -
> or when we have settable tsc counters (does Linux tweak them beyond aligning
> on SMP?).
>
> But there is also the risk the other way around: ns-to-tsc with frequency >
> 1GHz will fall apart (kernel oops!) when the user provides a large timeout
> in nanoseconds that we then try to convert to tsc. Not good. Wrong values
> are one thing, but oopses are even worse.
>
> Any idea how to fix this?
Since in the failure case the result of llimd would need 96 bits, the
only way is to make llimd result a 96 bits variable.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 12:17 ` Jan Kiszka
2008-04-03 12:27 ` Gilles Chanteperdrix
@ 2008-04-03 13:15 ` Sebastian Smolorz
2008-04-03 21:52 ` Jan Kiszka
1 sibling, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-03 13:15 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]
Jan Kiszka wrote:
> Sebastian Smolorz wrote:
>> Gilles Chanteperdrix wrote:
>>> On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
>>> <smolorz@domain.hid> wrote:
>>>> Jan Kiszka wrote:
>>>> > Sebastian Smolorz wrote:
>>>> >> Jan Kiszka wrote:
>>>> >>> Cornelius Köpp wrote:
>>>> >>>> I talked with Sebastian Smolorz about this and he builds his own
>>>> >>>> independent kernel-config to check. He got the same
>>>> drifting-effect
>>>> >>>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
>>>> >>>> hours. His kernel-config ist attached as
>>>> >>>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>>> >>>>
>>>> >>>> Our kernel-configs are both based on a config used with
>>>> Xenomai 2.3.4
>>>> >>>> and Linux 2.6.20.15 without any drifting effects.
>>>> >>> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe
>>>> it is
>>>> >>> not a PIC vs. APIC thing, but rather a rounding problem of
>>>> larger TSC
>>>> >>> values (that naturally show up when the system runs for a
>>>> longer time).
>>>> >> This hint seems to point into the right direction. I tried out a
>>>> >> modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the
>>>> old
>>>> >> implementation in include/asm-generic/bits/pod.h was used. The
>>>> drifting
>>>> >> bug disappeared. So there seems so be a buggy x86-specific
>>>> >> implementation of this routine.
>>>> >
>>>> > Hmm, maybe even a conceptional issue: the multiply-shift-based
>>>> > xnarch_tsc_to_ns is not as precise as the still
>>>> multiply-divide-based
>>>> > xnarch_ns_to_tsc. So when converting from tsc over ns back to
>>>> tsc, we
>>>> > may loose some bits, maybe too many bits...
>>>> >
>>>> > It looks like this bites us in the kernel latency tests (-t2 should
>>>> > suffer as well). Those recalculate their timeouts each round
>>>> based on
>>>> > absolute nanoseconds. In contrast, the periodic user mode task of
>>>> -t0
>>>> > uses a periodic timer that is forwarded via a tsc-based interval.
>>>> >
>>>> > You (or Cornelius) could try to analyse the calculation path of the
>>>> > involved timeouts, specifically to understand why the scheduled
>>>> timeout
>>>> > of the underlying task timer (which is tsc-based) tend to diverge
>>>> from
>>>> > the calculated one (ns-based).
>>>>
>>>> So here comes the explanation. The error is inside the function
>>>> rthal_llmulshft(). It returns wrong values which are too small - the
>>>> higher the given TSC value the bigger the error. The function
>>>> rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
>>>> rtdm_clock_read_monotonic() is called every time the latency kernel
>>>> thread runs [1] the values reported by latency become smaller over
>>>> time.
>>>>
>>>> In contrast, the latency task in user space only uses the conversion
>>>> from TSC to ns only once when calling rt_timer_inquire [2].
>>>> timer_info.date is too small, timer_info.tsc is right. So all
>>>> calculated
>>>> deltas in [3] are shifted to a smaller value. This value is constant
>>>> during the runtime of lateny in user space because no more conversion
>>>> from TSC to ns occurs.
>>>
>>> latency does conversions from tsc to ns, but it converts time
>>> differences, so the error is small relative to the results.
>>
>> Of course. I wasn't precise with my last statement. It should be: No
>> more conversions from *absolute* TSC values to ns occur.
>>
>
> This patch may do the trick: it uses the inverted tsc-to-ns function
> instead of the frequency-based one. Be warned, it is totally untested
> inside Xenomai, I just ran it in a user space test program. But it may
> give an idea.
Your patch needed two minor corrections (ns instead of ts in functions
xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
latency -t1 seems to prove your bug-fix: There seems to be no drift.
If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
precise but introduces a new function xnarch_ns_to_tsc() which is also
less precise than the generic xnarch_ns_to_tsc(), right? So isn't there
still the danger of getting wrong values when calling xnarch_tsc_to_ns()
not in combination with xnarch_ns_to_tsc()?
--
Sebastian
[-- Attachment #2: fixup-scaled-ns2tsc-conversion.patch --]
[-- Type: text/plain, Size: 2870 bytes --]
---
include/asm-x86/bits/init_32.h | 3 ++-
include/asm-x86/bits/init_64.h | 3 ++-
include/asm-x86/bits/pod_32.h | 7 +++++++
include/asm-x86/bits/pod_64.h | 7 +++++++
4 files changed, 18 insertions(+), 2 deletions(-)
Index: b/include/asm-x86/bits/init_32.h
===================================================================
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -73,7 +73,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -89,6 +89,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/init_64.h
===================================================================
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -70,7 +70,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -86,6 +86,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/pod_32.h
===================================================================
--- a/include/asm-x86/bits/pod_32.h
+++ b/include/asm-x86/bits/pod_32.h
@@ -25,6 +25,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -32,6 +33,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
Index: b/include/asm-x86/bits/pod_64.h
===================================================================
--- a/include/asm-x86/bits/pod_64.h
+++ b/include/asm-x86/bits/pod_64.h
@@ -24,6 +24,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -31,6 +32,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 13:15 ` Sebastian Smolorz
@ 2008-04-03 21:52 ` Jan Kiszka
2008-04-04 8:23 ` Sebastian Smolorz
0 siblings, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-03 21:52 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> This patch may do the trick: it uses the inverted tsc-to-ns function
>> instead of the frequency-based one. Be warned, it is totally untested
>> inside Xenomai, I just ran it in a user space test program. But it may
>> give an idea.
>
> Your patch needed two minor corrections (ns instead of ts in functions
> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
> latency -t1 seems to prove your bug-fix: There seems to be no drift.
That's good to hear.
> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
> precise but introduces a new function xnarch_ns_to_tsc() which is also
> less precise than the generic xnarch_ns_to_tsc(), right?
Yes. It is now precisely the inverse imprecision, so to say. :)
> So isn't there
> still the danger of getting wrong values when calling xnarch_tsc_to_ns()
> not in combination with xnarch_ns_to_tsc()?
Only if the user decides to implement his own conversion. Xenomai with
all its skins and both in kernel and user space should always run
through the xnarch_* path.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-03 21:52 ` Jan Kiszka
@ 2008-04-04 8:23 ` Sebastian Smolorz
2008-04-04 10:45 ` Jan Kiszka
0 siblings, 1 reply; 28+ messages in thread
From: Sebastian Smolorz @ 2008-04-04 8:23 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
Jan Kiszka wrote:
> Sebastian Smolorz wrote:
>> Jan Kiszka wrote:
>>> This patch may do the trick: it uses the inverted tsc-to-ns function
>>> instead of the frequency-based one. Be warned, it is totally untested
>>> inside Xenomai, I just ran it in a user space test program. But it
>>> may give an idea.
>>
>> Your patch needed two minor corrections (ns instead of ts in functions
>> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
>> latency -t1 seems to prove your bug-fix: There seems to be no drift.
>
> That's good to hear.
>
>> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
>> precise but introduces a new function xnarch_ns_to_tsc() which is also
>> less precise than the generic xnarch_ns_to_tsc(), right?
>
> Yes. It is now precisely the inverse imprecision, so to say. :)
>
>> So isn't there still the danger of getting wrong values when calling
>> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
>
> Only if the user decides to implement his own conversion. Xenomai with
> all its skins and both in kernel and user space should always run
> through the xnarch_* path.
OK, would you commit the patch?
--
Sebastian
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 8:23 ` Sebastian Smolorz
@ 2008-04-04 10:45 ` Jan Kiszka
2008-04-04 13:18 ` Gilles Chanteperdrix
0 siblings, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-04 10:45 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1.1: Type: text/plain, Size: 1418 bytes --]
Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> Sebastian Smolorz wrote:
>>> Jan Kiszka wrote:
>>>> This patch may do the trick: it uses the inverted tsc-to-ns function
>>>> instead of the frequency-based one. Be warned, it is totally
>>>> untested inside Xenomai, I just ran it in a user space test program.
>>>> But it may give an idea.
>>>
>>> Your patch needed two minor corrections (ns instead of ts in
>>> functions xnarch_ns_to_tsc()) in order to compile. A short run (30
>>> minutes) of latency -t1 seems to prove your bug-fix: There seems to
>>> be no drift.
>>
>> That's good to hear.
>>
>>> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
>>> precise but introduces a new function xnarch_ns_to_tsc() which is
>>> also less precise than the generic xnarch_ns_to_tsc(), right?
>>
>> Yes. It is now precisely the inverse imprecision, so to say. :)
>>
>>> So isn't there still the danger of getting wrong values when calling
>>> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
>>
>> Only if the user decides to implement his own conversion. Xenomai with
>> all its skins and both in kernel and user space should always run
>> through the xnarch_* path.
>
> OK, would you commit the patch?
Will do unless someone else has concerns. Gilles, Philippe? ARM and
Blackfin then need to be fixed similarly, full patch attached.
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fixup-scaled-ns2tsc-conversion.patch --]
[-- Type: text/x-patch; name="fixup-scaled-ns2tsc-conversion.patch", Size: 6549 bytes --]
---
ChangeLog | 7 +++++++
include/asm-arm/bits/init.h | 3 ++-
include/asm-arm/bits/pod.h | 7 +++++++
include/asm-blackfin/bits/init.h | 3 ++-
include/asm-blackfin/bits/pod.h | 7 +++++++
include/asm-x86/bits/init_32.h | 3 ++-
include/asm-x86/bits/init_64.h | 3 ++-
include/asm-x86/bits/pod_32.h | 7 +++++++
include/asm-x86/bits/pod_64.h | 7 +++++++
9 files changed, 43 insertions(+), 4 deletions(-)
Index: b/include/asm-x86/bits/init_32.h
===================================================================
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -73,7 +73,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -89,6 +89,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/init_64.h
===================================================================
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -70,7 +70,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -86,6 +86,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/pod_32.h
===================================================================
--- a/include/asm-x86/bits/pod_32.h
+++ b/include/asm-x86/bits/pod_32.h
@@ -25,6 +25,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -32,6 +33,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
Index: b/include/asm-x86/bits/pod_64.h
===================================================================
--- a/include/asm-x86/bits/pod_64.h
+++ b/include/asm-x86/bits/pod_64.h
@@ -24,6 +24,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -31,6 +32,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
#include <asm/xenomai/switch.h>
Index: b/include/asm-arm/bits/init.h
===================================================================
--- a/include/asm-arm/bits/init.h
+++ b/include/asm-arm/bits/init.h
@@ -67,7 +67,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -77,6 +77,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-arm/bits/pod.h
===================================================================
--- a/include/asm-arm/bits/pod.h
+++ b/include/asm-arm/bits/pod.h
@@ -25,6 +25,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -32,6 +33,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
void xnpod_welcome_thread(struct xnthread *, int);
Index: b/include/asm-blackfin/bits/init.h
===================================================================
--- a/include/asm-blackfin/bits/init.h
+++ b/include/asm-blackfin/bits/init.h
@@ -66,7 +66,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
__ipipe_irq_tail_hook = (unsigned long)&xnpod_schedule_deferred;
@@ -84,6 +84,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(1000000000, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-blackfin/bits/pod.h
===================================================================
--- a/include/asm-blackfin/bits/pod.h
+++ b/include/asm-blackfin/bits/pod.h
@@ -22,6 +22,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -29,6 +30,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include <asm-generic/xenomai/bits/pod.h>
void xnpod_welcome_thread(struct xnthread *, int);
Index: b/ChangeLog
===================================================================
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-04-04 Jan Kiszka <jan.kiszka@domain.hid>
+
+ * include/asm-*/{pod.h,init.h}: Introduce arch-specific
+ xnarch_ns_to_tsc as inverse of mul-shift xnarch_tsc_to_ns instead
+ of converting back via CPU frequency. Avoids drifts between large
+ calculated versus measured dates.
+
2008-04-02 Philippe Gerum <rpm@xenomai.org>
* include/asm-generic/bits/mlock_alert.h:
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 10:45 ` Jan Kiszka
@ 2008-04-04 13:18 ` Gilles Chanteperdrix
2008-04-04 13:25 ` Jan Kiszka
0 siblings, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-04 13:18 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Sebastian Smolorz wrote:
>
> > Jan Kiszka wrote:
> >
> > > Sebastian Smolorz wrote:
> > >
> > > > Jan Kiszka wrote:
> > > >
> > > > > This patch may do the trick: it uses the inverted tsc-to-ns function
> instead of the frequency-based one. Be warned, it is totally untested inside
> Xenomai, I just ran it in a user space test program. But it may give an
> idea.
> > > > >
> > > >
> > > > Your patch needed two minor corrections (ns instead of ts in functions
> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency
> -t1 seems to prove your bug-fix: There seems to be no drift.
> > > >
> > >
> > > That's good to hear.
> > >
> > >
> > > > If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
> precise but introduces a new function xnarch_ns_to_tsc() which is also less
> precise than the generic xnarch_ns_to_tsc(), right?
> > > >
> > >
> > > Yes. It is now precisely the inverse imprecision, so to say. :)
> > >
> > >
> > > > So isn't there still the danger of getting wrong values when calling
> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
> > > >
> > >
> > > Only if the user decides to implement his own conversion. Xenomai with
> all its skins and both in kernel and user space should always run through
> the xnarch_* path.
> > >
> >
> > OK, would you commit the patch?
> >
>
> Will do unless someone else has concerns. Gilles, Philippe? ARM and
> Blackfin then need to be fixed similarly, full patch attached.
Well, I am sorry, but I do not like this solution;
- the aim of scaled math is to avoid divisions, and with this patch we
end up using divisions;
- with scaled math we do wrong calculations, and making a wrong
xnarch_ns_to_tsc only works for values which should be passed to
xnarch_tsc_to_ns.
So, I would like to propose again my solution, which is exact, but use
no division. Its drawback is that it makes a few more additions and
multiplications than rthal_llimd, but has no division. If it happens
to be slower than llimd on some platforms (maybe x86 ?), I would use
llimd. After all, if the division is fast, we may be wrong to try and
avoid it.
For the records, here is the code:
typedef struct {
unsigned long long frac; /* Fractionary part. */
unsigned long integ; /* Integer part. */
} u32frac_t;
/* m/d == integ + frac / 2^64 */
static inline void precalc(u32frac_t *const f,
const unsigned long m,
const unsigned long d)
{
f->integ = m / d;
f->frac = div96by32(u32tou64(m % d, 0), 0, d, NULL);
}
unsigned long fast_imuldiv(unsigned long op, u32frac_t f)
{
const unsigned long tmp = (ullmul(op, f.frac >> 32)) >> 32;
if(f.integ)
return tmp + op * f.integ;
return tmp;
}
#define add64and32(h, l, s) do { \
__asm__ ("addl %2, %1\n\t" \
"adcl $0, %0" \
: "+r"(h), "+r"(l) \
: "r"(s)); \
} while(0)
#define add96and64(l0, l1, l2, s0, s1) do { \
__asm__ ("addl %4, %2\n\t" \
"adcl %3, %1\n\t" \
"adcl $0, %0\n\t" \
: "+r"(l0), "+r"(l1), "+r"(l2) \
: "r"(s0), "r"(s1)); \
} while(0)
static inline __attribute_const__ unsigned long long
mul64by64_high(const unsigned long long op, const unsigned long long m)
{
/* Compute high 64 bits of multiplication 64 bits x 64 bits. */
unsigned long long t1, t2, t3;
u_long oph, opl, mh, ml, t0, t1h, t1l, t2h, t2l, t3h, t3l;
u64tou32(op, oph, opl);
u64tou32(m, mh, ml);
t0 = ullmul(opl, ml) >> 32;
t1 = ullmul(oph, ml); u64tou32(t1, t1h, t1l);
add64and32(t1h, t1l, t0);
t2 = ullmul(opl, mh); u64tou32(t2, t2h, t2l);
t3 = ullmul(oph, mh); u64tou32(t3, t3h, t3l);
add64and32(t3h, t3l, t2h);
add96and64(t3h, t3l, t2l, t1h, t1l);
return u64fromu32(t3h, t3l);
}
static inline __attribute_const__ unsigned long long
fast_llimd(const unsigned long long op, const u32frac_t f)
{
const unsigned long long tmp = mul64by64_high(op, f.frac);
if(f.integ)
return tmp + op * f.integ;
return tmp;
}
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 13:18 ` Gilles Chanteperdrix
@ 2008-04-04 13:25 ` Jan Kiszka
2008-04-04 13:32 ` Jan Kiszka
2008-04-04 13:32 ` Gilles Chanteperdrix
0 siblings, 2 replies; 28+ messages in thread
From: Jan Kiszka @ 2008-04-04 13:25 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
Gilles Chanteperdrix wrote:
> On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Sebastian Smolorz wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Sebastian Smolorz wrote:
>>>>
>>>>> Jan Kiszka wrote:
>>>>>
>>>>>> This patch may do the trick: it uses the inverted tsc-to-ns function
>> instead of the frequency-based one. Be warned, it is totally untested inside
>> Xenomai, I just ran it in a user space test program. But it may give an
>> idea.
>>>>> Your patch needed two minor corrections (ns instead of ts in functions
>> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency
>> -t1 seems to prove your bug-fix: There seems to be no drift.
>>>> That's good to hear.
>>>>
>>>>
>>>>> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
>> precise but introduces a new function xnarch_ns_to_tsc() which is also less
>> precise than the generic xnarch_ns_to_tsc(), right?
>>>> Yes. It is now precisely the inverse imprecision, so to say. :)
>>>>
>>>>
>>>>> So isn't there still the danger of getting wrong values when calling
>> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
>>>> Only if the user decides to implement his own conversion. Xenomai with
>> all its skins and both in kernel and user space should always run through
>> the xnarch_* path.
>>> OK, would you commit the patch?
>>>
>> Will do unless someone else has concerns. Gilles, Philippe? ARM and
>> Blackfin then need to be fixed similarly, full patch attached.
>
> Well, I am sorry, but I do not like this solution;
> - the aim of scaled math is to avoid divisions, and with this patch we
> end up using divisions;
Please check again, no new division due to my patch, just different
parameters for the existing one.
> - with scaled math we do wrong calculations, and making a wrong
> xnarch_ns_to_tsc only works for values which should be passed to
> xnarch_tsc_to_ns.
IMHO, the error is within the range of the clock's precision, if not
even below. So struggling for mathematically precise conversion of
imprecise physical values makes no sense to me. Therefore I once
proposed the scaled-math optimization.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 13:25 ` Jan Kiszka
@ 2008-04-04 13:32 ` Jan Kiszka
2008-04-04 13:32 ` Gilles Chanteperdrix
1 sibling, 0 replies; 28+ messages in thread
From: Jan Kiszka @ 2008-04-04 13:32 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> Sebastian Smolorz wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>
>>>>> Sebastian Smolorz wrote:
>>>>>
>>>>>> Jan Kiszka wrote:
>>>>>>
>>>>>>> This patch may do the trick: it uses the inverted tsc-to-ns function
>>> instead of the frequency-based one. Be warned, it is totally untested
>>> inside
>>> Xenomai, I just ran it in a user space test program. But it may give an
>>> idea.
>>>>>> Your patch needed two minor corrections (ns instead of ts in
>>>>>> functions
>>> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
>>> latency
>>> -t1 seems to prove your bug-fix: There seems to be no drift.
>>>>> That's good to hear.
>>>>>
>>>>>
>>>>>> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
>>> precise but introduces a new function xnarch_ns_to_tsc() which is
>>> also less
>>> precise than the generic xnarch_ns_to_tsc(), right?
>>>>> Yes. It is now precisely the inverse imprecision, so to say. :)
>>>>>
>>>>>
>>>>>> So isn't there still the danger of getting wrong values when calling
>>> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
>>>>> Only if the user decides to implement his own conversion. Xenomai with
>>> all its skins and both in kernel and user space should always run
>>> through
>>> the xnarch_* path.
>>>> OK, would you commit the patch?
>>>>
>>> Will do unless someone else has concerns. Gilles, Philippe? ARM and
>>> Blackfin then need to be fixed similarly, full patch attached.
>>
>> Well, I am sorry, but I do not like this solution;
>> - the aim of scaled math is to avoid divisions, and with this patch we
>> end up using divisions;
>
> Please check again, no new division due to my patch, just different
> parameters for the existing one.
>
>> - with scaled math we do wrong calculations, and making a wrong
>> xnarch_ns_to_tsc only works for values which should be passed to
>> xnarch_tsc_to_ns.
>
> IMHO, the error is within the range of the clock's precision, if not
> even below. So struggling for mathematically precise conversion of
> imprecise physical values makes no sense to me. Therefore I once
> proposed the scaled-math optimization.
But this does not mean that I'm opposing even faster division-less
ns_to_tsc with scaled-math parameters, i.e. combining best of both worlds!
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 13:25 ` Jan Kiszka
2008-04-04 13:32 ` Jan Kiszka
@ 2008-04-04 13:32 ` Gilles Chanteperdrix
2008-04-04 13:57 ` Jan Kiszka
1 sibling, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-04 13:32 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
>
> > On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >
> > > Sebastian Smolorz wrote:
> > >
> > >
> > > > Jan Kiszka wrote:
> > > >
> > > >
> > > > > Sebastian Smolorz wrote:
> > > > >
> > > > >
> > > > > > Jan Kiszka wrote:
> > > > > >
> > > > > >
> > > > > > > This patch may do the trick: it uses the inverted tsc-to-ns
> function
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > instead of the frequency-based one. Be warned, it is totally untested
> inside
> > > Xenomai, I just ran it in a user space test program. But it may give an
> > > idea.
> > >
> > > >
> > > > >
> > > > > > Your patch needed two minor corrections (ns instead of ts in
> functions
> > > > > >
> > > > >
> > > >
> > > xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
> latency
> > > -t1 seems to prove your bug-fix: There seems to be no drift.
> > >
> > > >
> > > > > That's good to hear.
> > > > >
> > > > >
> > > > >
> > > > > > If I got your patch correctly, it doesn't make xnarch_tsc_to_ns
> more
> > > > > >
> > > > >
> > > >
> > > precise but introduces a new function xnarch_ns_to_tsc() which is also
> less
> > > precise than the generic xnarch_ns_to_tsc(), right?
> > >
> > > >
> > > > > Yes. It is now precisely the inverse imprecision, so to say. :)
> > > > >
> > > > >
> > > > >
> > > > > > So isn't there still the danger of getting wrong values when
> calling
> > > > > >
> > > > >
> > > >
> > > xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
> > >
> > > >
> > > > > Only if the user decides to implement his own conversion. Xenomai
> with
> > > > >
> > > >
> > > all its skins and both in kernel and user space should always run
> through
> > > the xnarch_* path.
> > >
> > > > OK, would you commit the patch?
> > > >
> > > >
> > > Will do unless someone else has concerns. Gilles, Philippe? ARM and
> > > Blackfin then need to be fixed similarly, full patch attached.
> > >
> >
> > Well, I am sorry, but I do not like this solution;
> > - the aim of scaled math is to avoid divisions, and with this patch we
> > end up using divisions;
> >
>
> Please check again, no new division due to my patch, just different
> parameters for the existing one.
I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was
using llimd, so does use division. My fast_llimd could be used to
replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc.
>
>
>
> > - with scaled math we do wrong calculations, and making a wrong
> > xnarch_ns_to_tsc only works for values which should be passed to
> > xnarch_tsc_to_ns.
> >
>
> IMHO, the error is within the range of the clock's precision, if not even
> below. So struggling for mathematically precise conversion of imprecise
> physical values makes no sense to me. Therefore I once proposed the
> scaled-math optimization.
Now that I have understood what really happens, I disagree with this
approach. Take the implementation of clock_gettime (or
rtdm_clock_read, for that matter). They basically do
xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small,
but in the very frequent use case of substracting two results of
consecutive reads of ipipe_read_tsc, the result of the substraction is
essentially garbage, because the result of the substraction may be of
the same order as the absolute error of the conversion. And I insist,
this use case of clock_gettime or rtdm_clock_read is a very realistic
use case.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 13:32 ` Gilles Chanteperdrix
@ 2008-04-04 13:57 ` Jan Kiszka
2008-04-04 14:09 ` Gilles Chanteperdrix
0 siblings, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-04 13:57 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 4089 bytes --]
Gilles Chanteperdrix wrote:
> On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>
>>>> Sebastian Smolorz wrote:
>>>>
>>>>
>>>>> Jan Kiszka wrote:
>>>>>
>>>>>
>>>>>> Sebastian Smolorz wrote:
>>>>>>
>>>>>>
>>>>>>> Jan Kiszka wrote:
>>>>>>>
>>>>>>>
>>>>>>>> This patch may do the trick: it uses the inverted tsc-to-ns
>> function
>>>> instead of the frequency-based one. Be warned, it is totally untested
>> inside
>>>> Xenomai, I just ran it in a user space test program. But it may give an
>>>> idea.
>>>>
>>>>>>> Your patch needed two minor corrections (ns instead of ts in
>> functions
>>>> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
>> latency
>>>> -t1 seems to prove your bug-fix: There seems to be no drift.
>>>>
>>>>>> That's good to hear.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns
>> more
>>>> precise but introduces a new function xnarch_ns_to_tsc() which is also
>> less
>>>> precise than the generic xnarch_ns_to_tsc(), right?
>>>>
>>>>>> Yes. It is now precisely the inverse imprecision, so to say. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So isn't there still the danger of getting wrong values when
>> calling
>>>> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
>>>>
>>>>>> Only if the user decides to implement his own conversion. Xenomai
>> with
>>>> all its skins and both in kernel and user space should always run
>> through
>>>> the xnarch_* path.
>>>>
>>>>> OK, would you commit the patch?
>>>>>
>>>>>
>>>> Will do unless someone else has concerns. Gilles, Philippe? ARM and
>>>> Blackfin then need to be fixed similarly, full patch attached.
>>>>
>>> Well, I am sorry, but I do not like this solution;
>>> - the aim of scaled math is to avoid divisions, and with this patch we
>>> end up using divisions;
>>>
>> Please check again, no new division due to my patch, just different
>> parameters for the existing one.
>
> I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was
> using llimd, so does use division. My fast_llimd could be used to
> replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc.
>
>>
>>
>>> - with scaled math we do wrong calculations, and making a wrong
>>> xnarch_ns_to_tsc only works for values which should be passed to
>>> xnarch_tsc_to_ns.
>>>
>> IMHO, the error is within the range of the clock's precision, if not even
>> below. So struggling for mathematically precise conversion of imprecise
>> physical values makes no sense to me. Therefore I once proposed the
>> scaled-math optimization.
>
> Now that I have understood what really happens, I disagree with this
> approach. Take the implementation of clock_gettime (or
> rtdm_clock_read, for that matter). They basically do
> xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small,
> but in the very frequent use case of substracting two results of
> consecutive reads of ipipe_read_tsc, the result of the substraction is
> essentially garbage, because the result of the substraction may be of
> the same order as the absolute error of the conversion. And I insist,
> this use case of clock_gettime or rtdm_clock_read is a very realistic
> use case.
This use case is valid, but I don't see the error scenario you sketch:
The error of the conversion is only relevant for large deltas,
tsc_to_ns(B)-tsc_to_ns(A)=B-A for any small B-A. Cornelius' test nicely
showed constantly increasing deviation, not something that jumped
around. Essentially, we are just replacing
xnarch_llimd(ts, 1000000000, RTHAL_CPU_FREQ);
with
xnarch_llimd(ts, xnarch_tsc_scale, 1<<xnarch_tsc_shift);
which introduces a linearly increasing error of the _absolute_ results,
not of relative ones. But if you can prove me wrong, I would take
everything back and agree on kicking out the scaled math immediately!
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 13:57 ` Jan Kiszka
@ 2008-04-04 14:09 ` Gilles Chanteperdrix
2008-04-04 14:33 ` Jan Kiszka
0 siblings, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-04 14:09 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Fri, Apr 4, 2008 at 3:57 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
>
> > On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >
> > > Gilles Chanteperdrix wrote:
> > >
> > >
> > > > On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> > > >
> > > >
> > > > > Sebastian Smolorz wrote:
> > > > >
> > > > >
> > > > >
> > > > > > Jan Kiszka wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Sebastian Smolorz wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Jan Kiszka wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > This patch may do the trick: it uses the inverted tsc-to-ns
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > function
> > >
> > > >
> > > > > instead of the frequency-based one. Be warned, it is totally
> untested
> > > > >
> > > >
> > > inside
> > >
> > > >
> > > > > Xenomai, I just ran it in a user space test program. But it may give
> an
> > > > > idea.
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > Your patch needed two minor corrections (ns instead of ts in
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > functions
> > >
> > > >
> > > > > xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
> > > > >
> > > >
> > > latency
> > >
> > > >
> > > > > -t1 seems to prove your bug-fix: There seems to be no drift.
> > > > >
> > > > >
> > > > > >
> > > > > > > That's good to hear.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > If I got your patch correctly, it doesn't make
> xnarch_tsc_to_ns
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > more
> > >
> > > >
> > > > > precise but introduces a new function xnarch_ns_to_tsc() which is
> also
> > > > >
> > > >
> > > less
> > >
> > > >
> > > > > precise than the generic xnarch_ns_to_tsc(), right?
> > > > >
> > > > >
> > > > > >
> > > > > > > Yes. It is now precisely the inverse imprecision, so to say. :)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > So isn't there still the danger of getting wrong values when
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > calling
> > >
> > > >
> > > > > xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
> > > > >
> > > > >
> > > > > >
> > > > > > > Only if the user decides to implement his own conversion.
> Xenomai
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > with
> > >
> > > >
> > > > > all its skins and both in kernel and user space should always run
> > > > >
> > > >
> > > through
> > >
> > > >
> > > > > the xnarch_* path.
> > > > >
> > > > >
> > > > > > OK, would you commit the patch?
> > > > > >
> > > > > >
> > > > > >
> > > > > Will do unless someone else has concerns. Gilles, Philippe? ARM and
> > > > > Blackfin then need to be fixed similarly, full patch attached.
> > > > >
> > > > >
> > > > Well, I am sorry, but I do not like this solution;
> > > > - the aim of scaled math is to avoid divisions, and with this patch we
> > > > end up using divisions;
> > > >
> > > >
> > > Please check again, no new division due to my patch, just different
> > > parameters for the existing one.
> > >
> >
> > I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was
> > using llimd, so does use division. My fast_llimd could be used to
> > replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc.
> >
> >
> > >
> > >
> > >
> > > > - with scaled math we do wrong calculations, and making a wrong
> > > > xnarch_ns_to_tsc only works for values which should be passed to
> > > > xnarch_tsc_to_ns.
> > > >
> > > >
> > > IMHO, the error is within the range of the clock's precision, if not
> even
> > > below. So struggling for mathematically precise conversion of imprecise
> > > physical values makes no sense to me. Therefore I once proposed the
> > > scaled-math optimization.
> > >
> >
> > Now that I have understood what really happens, I disagree with this
> > approach. Take the implementation of clock_gettime (or
> > rtdm_clock_read, for that matter). They basically do
> > xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small,
> > but in the very frequent use case of substracting two results of
> > consecutive reads of ipipe_read_tsc, the result of the substraction is
> > essentially garbage, because the result of the substraction may be of
> > the same order as the absolute error of the conversion. And I insist,
> > this use case of clock_gettime or rtdm_clock_read is a very realistic
> > use case.
> >
>
> This use case is valid, but I don't see the error scenario you sketch: The
> error of the conversion is only relevant for large deltas,
> tsc_to_ns(B)-tsc_to_ns(A)=B-A for any small B-A. Cornelius' test nicely
> showed constantly increasing deviation, not something that jumped around.
> Essentially, we are just replacing
>
> xnarch_llimd(ts, 1000000000, RTHAL_CPU_FREQ);
>
> with
>
> xnarch_llimd(ts, xnarch_tsc_scale, 1<<xnarch_tsc_shift);
>
> which introduces a linearly increasing error of the _absolute_ results, not
> of relative ones. But if you can prove me wrong, I would take everything
> back and agree on kicking out the scaled math immediately!
Right. We are approximating a fraction with another fraction. But my
first impression remains: I do not like the idea of making
xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 14:09 ` Gilles Chanteperdrix
@ 2008-04-04 14:33 ` Jan Kiszka
2008-04-04 15:48 ` Gilles Chanteperdrix
0 siblings, 1 reply; 28+ messages in thread
From: Jan Kiszka @ 2008-04-04 14:33 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core, Cornelius Köpp
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Gilles Chanteperdrix wrote:
> Right. We are approximating a fraction with another fraction. But my
> first impression remains: I do not like the idea of making
> xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong.
Well, my first impression was originally the same: If we still need
llimd in the ns-to-tsc patch, then we should keep the precise way. But
that was wrong as this thread demonstrated. We have to ensure that
ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So
either use scaled math parameters in both ways or fall back to the
original calculation.
However the final decision for 2.5 is (pro or contra scaled math), at
least for 2.4.x we have to fix things now without turning the upside
down. That means apply my patch or revert scaled-math optimizations for
all archs.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 14:33 ` Jan Kiszka
@ 2008-04-04 15:48 ` Gilles Chanteperdrix
2008-04-04 15:52 ` Philippe Gerum
0 siblings, 1 reply; 28+ messages in thread
From: Gilles Chanteperdrix @ 2008-04-04 15:48 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core, Cornelius Köpp
On Fri, Apr 4, 2008 at 4:33 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
>
> > Right. We are approximating a fraction with another fraction. But my
> > first impression remains: I do not like the idea of making
> > xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong.
> >
>
> Well, my first impression was originally the same: If we still need llimd
> in the ns-to-tsc patch, then we should keep the precise way. But that was
> wrong as this thread demonstrated. We have to ensure that
> ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So
> either use scaled math parameters in both ways or fall back to the original
> calculation.
Now that I think about it, this scaled math approach is about taking
an approximation of the CPU frequency, which is already approximative.
So, I will not oppose longer to your patch.
>
> However the final decision for 2.5 is (pro or contra scaled math), at least
> for 2.4.x we have to fix things now without turning the upside down. That
> means apply my patch or revert scaled-math optimizations for all archs.
--
Gilles
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
2008-04-04 15:48 ` Gilles Chanteperdrix
@ 2008-04-04 15:52 ` Philippe Gerum
0 siblings, 0 replies; 28+ messages in thread
From: Philippe Gerum @ 2008-04-04 15:52 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core, Cornelius Köpp
Gilles Chanteperdrix wrote:
> On Fri, Apr 4, 2008 at 4:33 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> Right. We are approximating a fraction with another fraction. But my
>>> first impression remains: I do not like the idea of making
>>> xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong.
>>>
>> Well, my first impression was originally the same: If we still need llimd
>> in the ns-to-tsc patch, then we should keep the precise way. But that was
>> wrong as this thread demonstrated. We have to ensure that
>> ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So
>> either use scaled math parameters in both ways or fall back to the original
>> calculation.
>
> Now that I think about it, this scaled math approach is about taking
> an approximation of the CPU frequency, which is already approximative.
> So, I will not oppose longer to your patch.
>
Ok, so I take this for a green light to commit too. Please commit.
>> However the final decision for 2.5 is (pro or contra scaled math), at least
>> for 2.4.x we have to fix things now without turning the upside down. That
>> means apply my patch or revert scaled-math optimizations for all archs.
>
>
>
--
Philippe.
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-04-04 15:52 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-01 23:26 [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3) Cornelius Köpp
2008-04-02 3:01 ` Tomas Kalibera
2008-04-02 9:04 ` Jan Kiszka
2008-04-02 12:00 ` Sebastian Smolorz
2008-04-02 12:28 ` Jan Kiszka
2008-04-02 12:46 ` Gilles Chanteperdrix
2008-04-02 13:00 ` Sebastian Smolorz
2008-04-02 15:28 ` Sebastian Smolorz
2008-04-02 15:58 ` Sebastian Smolorz
2008-04-02 16:05 ` Gilles Chanteperdrix
2008-04-02 16:24 ` Sebastian Smolorz
2008-04-03 12:17 ` Jan Kiszka
2008-04-03 12:27 ` Gilles Chanteperdrix
2008-04-03 12:50 ` Jan Kiszka
2008-04-03 12:52 ` Gilles Chanteperdrix
2008-04-03 13:15 ` Sebastian Smolorz
2008-04-03 21:52 ` Jan Kiszka
2008-04-04 8:23 ` Sebastian Smolorz
2008-04-04 10:45 ` Jan Kiszka
2008-04-04 13:18 ` Gilles Chanteperdrix
2008-04-04 13:25 ` Jan Kiszka
2008-04-04 13:32 ` Jan Kiszka
2008-04-04 13:32 ` Gilles Chanteperdrix
2008-04-04 13:57 ` Jan Kiszka
2008-04-04 14:09 ` Gilles Chanteperdrix
2008-04-04 14:33 ` Jan Kiszka
2008-04-04 15:48 ` Gilles Chanteperdrix
2008-04-04 15:52 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.