* [Xenomai-help] Priority coupling broken?
@ 2011-03-29 14:41 Henri Roosen
2011-03-29 15:28 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Henri Roosen @ 2011-03-29 14:41 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
Hi,
I have several Xenomai RT threads (prio > 0) that get ready to run all
at the same time. Priority coupling is enabled in the kernel.
If one of them (unfortunately) makes a Linux system call, I see that
first other lower and same priority Xenomai tasks are scheduled before
the switched task is run in the Linux domain. As I understand,
priority coupling should prevent this.
To rule out a problem in the application, this is also tested with a
simple application based on the rt_print example. In my opinion, with
priority coupling enabled this should print:
Wakeup! - I am - awake! - Me too!
But I get:
Wakeup! - I am - Me too! - awake!
So task 2 gets run before task 3 completes in the Linux domain.
Please find attached the test application and the .config file.
Xenomai 2.5.6
Linux 2.6.32.20
adeos-ipipe-2.6.32.20-x86-2.7-03.patch
Thanks,
Henri.
[-- Attachment #2: tst_prio_cpl.c --]
[-- Type: text/x-csrc, Size: 1691 bytes --]
#include <stdio.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/event.h>
#include <rtdk.h>
#include <sys/time.h>
RT_EVENT evnt;
static void task3_func(void *arg)
{
struct timeval tv;
unsigned long old;
rt_printf("This triggers auto-init of rt_print for the "
"calling thread.\n");
while (1) {
rt_event_wait(&evnt, 1, &old, EV_ANY, TM_INFINITE);
rt_event_clear(&evnt, 1, NULL);
rt_printf("I am\n");
/* Syscall here to force switch to secondary */
gettimeofday(&tv, NULL);
rt_printf("awake!\n");
}
}
static void task2_func(void *arg)
{
unsigned long old;
rt_printf("This triggers auto-init of rt_print for the "
"calling thread.\n"
"A last switch to secondary mode can occure here, "
"but future invocations of rt_printf are safe.\n");
rt_task_set_mode(0, T_WARNSW, NULL);
while (1) {
rt_event_wait(&evnt, 2, &old, EV_ANY, TM_INFINITE);
rt_event_clear(&evnt, 2, NULL);
rt_printf("Me too!\n");
}
}
int main(int argc, char **argv)
{
RT_TASK task1, task2, task3;
mlockall(MCL_CURRENT|MCL_FUTURE);
/* Perform auto-init of rt_print buffers if the task doesn't do so */
rt_print_auto_init(1);
/* Initialise the rt_print buffer for this task explicitly */
rt_print_init(4096, "Task 1");
rt_event_create(&evnt, "Evnt", 0, EV_PRIO);
rt_task_shadow(&task1, "Task 1", 10, 0);
rt_task_spawn(&task2, "Task 2", 0, 11, 0, task2_func, NULL);
rt_task_spawn(&task3, "Task 3", 0, 12, 0, task3_func, NULL);
/* To demonstrate that rt_printf is safe */
rt_task_set_mode(0, T_WARNSW, NULL);
while (1) {
rt_task_sleep(1000000000LL);
rt_printf("Wakeup!\n");
/* Signal both events */
rt_event_signal(&evnt, 3);
}
}
[-- Attachment #3: config.xenomai-2.5.6.linux-2.6.32.20 --]
[-- Type: application/octet-stream, Size: 46542 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.20
# Thu Mar 10 13:47:23 2011
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
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_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=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_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
#
# GCOV-based kernel profiling
#
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
# CONFIG_XENO_OPT_SHIRQ is not set
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
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=1024
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_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
CONFIG_XENO_OPT_NATIVE_INTR=y
CONFIG_XENO_SKIN_POSIX=y
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=y
# 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_OPT_NOWARN_DEPRECATED 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
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
# CONFIG_XENO_DRIVERS_TESTING_LEGACY_NAMES is not set
# CONFIG_XENO_DRIVERS_TIMERBENCH is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
# CONFIG_XENO_DRIVERS_SWITCHTEST is not set
# CONFIG_XENO_DRIVERS_SIGTEST is not set
# CONFIG_XENO_DRIVERS_RTDMTEST is not set
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
# CONFIG_FREEZER is not set
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_MRST is not set
# CONFIG_X86_RDC321X is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_MEMTEST 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_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_MATOM is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
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_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
# CONFIG_HPET_TIMER is not set
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=1
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_COMPAT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_IPIPE_UNMASKED_CONTEXT_SWITCH is not set
# 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_PHYS_ADDR_T_64BIT is not set
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
#
# Power management and ACPI options
#
# CONFIG_PM is not set
# CONFIG_SFI is not set
#
# 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_GOOLPC 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_STUB is not set
# CONFIG_PCI_IOV 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_OLPC is not set
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE 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_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_ATM is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_PHONET is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
CONFIG_CFG80211_REG_DEBUG=y
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_DEFAULT_PS_VALUE=1
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=y
CONFIG_LIB80211_DEBUG=y
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
# CONFIG_MAC80211_RC_PID is not set
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUG_MENU=y
CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT=y
CONFIG_MAC80211_NOINLINE=y
CONFIG_MAC80211_VERBOSE_DEBUG=y
CONFIG_MAC80211_HT_DEBUG=y
CONFIG_MAC80211_TKIP_DEBUG=y
CONFIG_MAC80211_IBSS_DEBUG=y
CONFIG_MAC80211_VERBOSE_PS_DEBUG=y
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_SERIAL=y
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPACPI is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_UB=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y
#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_ATAPI=y
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
# CONFIG_IDE_GD_ATAPI is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set
#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=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_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_CS5536 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=y
# CONFIG_BLK_DEV_IT8172 is not set
# CONFIG_BLK_DEV_IT8213 is not set
CONFIG_BLK_DEV_IT821X=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 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=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_ISAPNP is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_SCH is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# You can enable one or both FireWire driver stacks.
#
#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA 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_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
CONFIG_8139TOO=y
# 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_R6040=y
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
# CONFIG_ATL2 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_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
# CONFIG_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
#
# USB Network Adapters
#
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
CONFIG_INPUT_POWERMATE=y
CONFIG_INPUT_UINPUT=y
# CONFIG_INPUT_WINBOND_CIR is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=8
CONFIG_SERIAL_8250_RUNTIME_UARTS=8
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=y
CONFIG_SERIAL_8250_ACCENT=y
CONFIG_SERIAL_8250_BOCA=y
CONFIG_SERIAL_8250_EXAR_ST16C554=y
CONFIG_SERIAL_8250_HUB6=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM 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_DEVPORT=y
# CONFIG_I2C is not set
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_TLE62X0 is not set
#
# PPS support
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_MC13783 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
# CONFIG_DRM is not set
CONFIG_VGASTATE=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
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_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# 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=y
CONFIG_FB_VESA=y
# CONFIG_FB_N411 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_LE80578 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_SIS=y
# CONFIG_FB_SIS_300 is not set
CONFIG_FB_SIS_315=y
# CONFIG_FB_VIA 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_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
CONFIG_LOGO_LINUX_VGA16=y
# CONFIG_LOGO_LINUX_CLUT224 is not set
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS 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=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES 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_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_GADGET_MUSB_HDRC is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_ONETOUCH=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_STORAGE_CYPRESS_ATACB=y
CONFIG_USB_LIBUSUAL=y
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_EZUSB is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE 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_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# 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_IUU 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_MOTOROLA 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_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL 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_OPTICON 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_SEVSEG 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_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
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG_FILES is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_SELECTED=y
CONFIG_USB_GADGET_VORTEX86DX=y
CONFIG_USB_VORTEX86DX=y
# CONFIG_USB_GADGET_AT91 is not set
# CONFIG_USB_GADGET_ATMEL_USBA is not set
# CONFIG_USB_GADGET_FSL_USB2 is not set
# CONFIG_USB_GADGET_LH7A40X is not set
# CONFIG_USB_GADGET_OMAP is not set
# CONFIG_USB_GADGET_PXA25X is not set
# CONFIG_USB_GADGET_R8A66597 is not set
# CONFIG_USB_GADGET_PXA27X is not set
# CONFIG_USB_GADGET_S3C_HSOTG is not set
# CONFIG_USB_GADGET_IMX is not set
# CONFIG_USB_GADGET_S3C2410 is not set
# CONFIG_USB_GADGET_M66592 is not set
# CONFIG_USB_GADGET_AMD5536UDC is not set
# CONFIG_USB_GADGET_FSL_QE is not set
# CONFIG_USB_GADGET_CI13XXX is not set
# CONFIG_USB_GADGET_NET2280 is not set
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_LANGWELL is not set
# CONFIG_USB_GADGET_DUMMY_HCD is not set
# CONFIG_USB_GADGET_DUALSPEED is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FILE_STORAGE is not set
CONFIG_USB_G_SERIAL=y
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_UNSAFE_RESUME=y
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
CONFIG_MMC_TEST=y
#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y
CONFIG_MMC_RICOH_MMC=y
# CONFIG_MMC_SDHCI_PLTFM is not set
CONFIG_MMC_WBSD=y
# CONFIG_MMC_AT91 is not set
# CONFIG_MMC_ATMELMCI is not set
CONFIG_MMC_SPI=y
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
# CONFIG_LEDS_CLASS is not set
#
# LED drivers
#
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_IDE_DISK is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
#
# TI VLYNQ
#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_FS_XIP=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# Caches
#
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS 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 is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=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
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_HFSPLUS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
CONFIG_NLS_CODEPAGE_864=y
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=y
CONFIG_NLS_CODEPAGE_949=y
CONFIG_NLS_CODEPAGE_874=y
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
CONFIG_NLS_ISO8859_4=y
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=y
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS 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 is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_4KSTACKS is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_OPTIMIZE_INLINING=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_PCBC is not set
#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 14:41 [Xenomai-help] Priority coupling broken? Henri Roosen
@ 2011-03-29 15:28 ` Philippe Gerum
2011-03-29 19:11 ` Gilles Chanteperdrix
0 siblings, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-03-29 15:28 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> Hi,
>
> I have several Xenomai RT threads (prio > 0) that get ready to run all
> at the same time. Priority coupling is enabled in the kernel.
>
> If one of them (unfortunately) makes a Linux system call, I see that
> first other lower and same priority Xenomai tasks are scheduled before
> the switched task is run in the Linux domain. As I understand,
> priority coupling should prevent this.
>
> To rule out a problem in the application, this is also tested with a
> simple application based on the rt_print example. In my opinion, with
> priority coupling enabled this should print:
> Wakeup! - I am - awake! - Me too!
> But I get:
> Wakeup! - I am - Me too! - awake!
> So task 2 gets run before task 3 completes in the Linux domain.
>
> Please find attached the test application and the .config file.
The fine print with priority coupling is that it stops immediately
whenever the thread blocks linux-wise; this is actually why, after all
this time debugging it, I'm pondering now whether I should keep this
behavior/feature in 3.x.
Initially, this was aimed at enforcing the right scheduling sequence
with traditional RTOS APIs, specifically when it comes to create
threads, so that high priority children do run prior to low priority
parents (some legacy apps may expect this). But the fact is that this
behavior also carries a number of uncertainties, and having the thread
de-boosted when blocked by Linux is a serious one.
Anyway, please try the following:
- do not use rt_printf() to monitor the sequence, but a data array of
some sort to track the switches, and report the contents of that array
at the end of the test.
- replace gettimeofday() with sched_yield().
TIA,
>
> Xenomai 2.5.6
> Linux 2.6.32.20
> adeos-ipipe-2.6.32.20-x86-2.7-03.patch
>
> Thanks,
> Henri.
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 15:28 ` Philippe Gerum
@ 2011-03-29 19:11 ` Gilles Chanteperdrix
2011-03-29 19:17 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-29 19:11 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>> Hi,
>>
>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>> at the same time. Priority coupling is enabled in the kernel.
>>
>> If one of them (unfortunately) makes a Linux system call, I see that
>> first other lower and same priority Xenomai tasks are scheduled before
>> the switched task is run in the Linux domain. As I understand,
>> priority coupling should prevent this.
>>
>> To rule out a problem in the application, this is also tested with a
>> simple application based on the rt_print example. In my opinion, with
>> priority coupling enabled this should print:
>> Wakeup! - I am - awake! - Me too!
>> But I get:
>> Wakeup! - I am - Me too! - awake!
>> So task 2 gets run before task 3 completes in the Linux domain.
>>
>> Please find attached the test application and the .config file.
>
> The fine print with priority coupling is that it stops immediately
> whenever the thread blocks linux-wise; this is actually why, after all
> this time debugging it, I'm pondering now whether I should keep this
> behavior/feature in 3.x.
>
> Initially, this was aimed at enforcing the right scheduling sequence
> with traditional RTOS APIs, specifically when it comes to create
> threads, so that high priority children do run prior to low priority
> parents (some legacy apps may expect this). But the fact is that this
> behavior also carries a number of uncertainties, and having the thread
> de-boosted when blocked by Linux is a serious one.
Maybe each thread could have a bit telling whether or not it should run
under priority coupling, this bit would be disabled at all times, except
during the thread creation routines, and at other times if the user
called xnpod_set_mode to enable it if he wants?
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 19:11 ` Gilles Chanteperdrix
@ 2011-03-29 19:17 ` Philippe Gerum
2011-03-29 19:19 ` Gilles Chanteperdrix
0 siblings, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-03-29 19:17 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> >> Hi,
> >>
> >> I have several Xenomai RT threads (prio > 0) that get ready to run all
> >> at the same time. Priority coupling is enabled in the kernel.
> >>
> >> If one of them (unfortunately) makes a Linux system call, I see that
> >> first other lower and same priority Xenomai tasks are scheduled before
> >> the switched task is run in the Linux domain. As I understand,
> >> priority coupling should prevent this.
> >>
> >> To rule out a problem in the application, this is also tested with a
> >> simple application based on the rt_print example. In my opinion, with
> >> priority coupling enabled this should print:
> >> Wakeup! - I am - awake! - Me too!
> >> But I get:
> >> Wakeup! - I am - Me too! - awake!
> >> So task 2 gets run before task 3 completes in the Linux domain.
> >>
> >> Please find attached the test application and the .config file.
> >
> > The fine print with priority coupling is that it stops immediately
> > whenever the thread blocks linux-wise; this is actually why, after all
> > this time debugging it, I'm pondering now whether I should keep this
> > behavior/feature in 3.x.
> >
> > Initially, this was aimed at enforcing the right scheduling sequence
> > with traditional RTOS APIs, specifically when it comes to create
> > threads, so that high priority children do run prior to low priority
> > parents (some legacy apps may expect this). But the fact is that this
> > behavior also carries a number of uncertainties, and having the thread
> > de-boosted when blocked by Linux is a serious one.
>
> Maybe each thread could have a bit telling whether or not it should run
> under priority coupling, this bit would be disabled at all times, except
> during the thread creation routines, and at other times if the user
> called xnpod_set_mode to enable it if he wants?
>
This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
makes sense to provide priority coupling without any mean to actually
control the impact the regular kernel may have on it.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 19:17 ` Philippe Gerum
@ 2011-03-29 19:19 ` Gilles Chanteperdrix
2011-03-29 19:27 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-29 19:19 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>>>> Hi,
>>>>
>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>>>> at the same time. Priority coupling is enabled in the kernel.
>>>>
>>>> If one of them (unfortunately) makes a Linux system call, I see that
>>>> first other lower and same priority Xenomai tasks are scheduled before
>>>> the switched task is run in the Linux domain. As I understand,
>>>> priority coupling should prevent this.
>>>>
>>>> To rule out a problem in the application, this is also tested with a
>>>> simple application based on the rt_print example. In my opinion, with
>>>> priority coupling enabled this should print:
>>>> Wakeup! - I am - awake! - Me too!
>>>> But I get:
>>>> Wakeup! - I am - Me too! - awake!
>>>> So task 2 gets run before task 3 completes in the Linux domain.
>>>>
>>>> Please find attached the test application and the .config file.
>>> The fine print with priority coupling is that it stops immediately
>>> whenever the thread blocks linux-wise; this is actually why, after all
>>> this time debugging it, I'm pondering now whether I should keep this
>>> behavior/feature in 3.x.
>>>
>>> Initially, this was aimed at enforcing the right scheduling sequence
>>> with traditional RTOS APIs, specifically when it comes to create
>>> threads, so that high priority children do run prior to low priority
>>> parents (some legacy apps may expect this). But the fact is that this
>>> behavior also carries a number of uncertainties, and having the thread
>>> de-boosted when blocked by Linux is a serious one.
>> Maybe each thread could have a bit telling whether or not it should run
>> under priority coupling, this bit would be disabled at all times, except
>> during the thread creation routines, and at other times if the user
>> called xnpod_set_mode to enable it if he wants?
>>
>
> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> makes sense to provide priority coupling without any mean to actually
> control the impact the regular kernel may have on it.
>
without the irq shield you mean :-)
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 19:19 ` Gilles Chanteperdrix
@ 2011-03-29 19:27 ` Philippe Gerum
2011-03-29 19:29 ` Gilles Chanteperdrix
0 siblings, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-03-29 19:27 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> >>>> Hi,
> >>>>
> >>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
> >>>> at the same time. Priority coupling is enabled in the kernel.
> >>>>
> >>>> If one of them (unfortunately) makes a Linux system call, I see that
> >>>> first other lower and same priority Xenomai tasks are scheduled before
> >>>> the switched task is run in the Linux domain. As I understand,
> >>>> priority coupling should prevent this.
> >>>>
> >>>> To rule out a problem in the application, this is also tested with a
> >>>> simple application based on the rt_print example. In my opinion, with
> >>>> priority coupling enabled this should print:
> >>>> Wakeup! - I am - awake! - Me too!
> >>>> But I get:
> >>>> Wakeup! - I am - Me too! - awake!
> >>>> So task 2 gets run before task 3 completes in the Linux domain.
> >>>>
> >>>> Please find attached the test application and the .config file.
> >>> The fine print with priority coupling is that it stops immediately
> >>> whenever the thread blocks linux-wise; this is actually why, after all
> >>> this time debugging it, I'm pondering now whether I should keep this
> >>> behavior/feature in 3.x.
> >>>
> >>> Initially, this was aimed at enforcing the right scheduling sequence
> >>> with traditional RTOS APIs, specifically when it comes to create
> >>> threads, so that high priority children do run prior to low priority
> >>> parents (some legacy apps may expect this). But the fact is that this
> >>> behavior also carries a number of uncertainties, and having the thread
> >>> de-boosted when blocked by Linux is a serious one.
> >> Maybe each thread could have a bit telling whether or not it should run
> >> under priority coupling, this bit would be disabled at all times, except
> >> during the thread creation routines, and at other times if the user
> >> called xnpod_set_mode to enable it if he wants?
> >>
> >
> > This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> > makes sense to provide priority coupling without any mean to actually
> > control the impact the regular kernel may have on it.
> >
> without the irq shield you mean :-)
>
No, it is not related. The issue now is with the inability to determine
whether and when the kernel may cause the priority boost to drop without
the user knowing about it.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 19:27 ` Philippe Gerum
@ 2011-03-29 19:29 ` Gilles Chanteperdrix
2011-03-30 4:58 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-29 19:29 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>>>> Philippe Gerum wrote:
>>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>>>>>> at the same time. Priority coupling is enabled in the kernel.
>>>>>>
>>>>>> If one of them (unfortunately) makes a Linux system call, I see that
>>>>>> first other lower and same priority Xenomai tasks are scheduled before
>>>>>> the switched task is run in the Linux domain. As I understand,
>>>>>> priority coupling should prevent this.
>>>>>>
>>>>>> To rule out a problem in the application, this is also tested with a
>>>>>> simple application based on the rt_print example. In my opinion, with
>>>>>> priority coupling enabled this should print:
>>>>>> Wakeup! - I am - awake! - Me too!
>>>>>> But I get:
>>>>>> Wakeup! - I am - Me too! - awake!
>>>>>> So task 2 gets run before task 3 completes in the Linux domain.
>>>>>>
>>>>>> Please find attached the test application and the .config file.
>>>>> The fine print with priority coupling is that it stops immediately
>>>>> whenever the thread blocks linux-wise; this is actually why, after all
>>>>> this time debugging it, I'm pondering now whether I should keep this
>>>>> behavior/feature in 3.x.
>>>>>
>>>>> Initially, this was aimed at enforcing the right scheduling sequence
>>>>> with traditional RTOS APIs, specifically when it comes to create
>>>>> threads, so that high priority children do run prior to low priority
>>>>> parents (some legacy apps may expect this). But the fact is that this
>>>>> behavior also carries a number of uncertainties, and having the thread
>>>>> de-boosted when blocked by Linux is a serious one.
>>>> Maybe each thread could have a bit telling whether or not it should run
>>>> under priority coupling, this bit would be disabled at all times, except
>>>> during the thread creation routines, and at other times if the user
>>>> called xnpod_set_mode to enable it if he wants?
>>>>
>>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
>>> makes sense to provide priority coupling without any mean to actually
>>> control the impact the regular kernel may have on it.
>>>
>> without the irq shield you mean :-)
>>
>
> No, it is not related. The issue now is with the inability to determine
> whether and when the kernel may cause the priority boost to drop without
> the user knowing about it.
>
Maybe we could add a new SIGDEBUG reason ?
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-29 19:29 ` Gilles Chanteperdrix
@ 2011-03-30 4:58 ` Philippe Gerum
2011-03-30 7:30 ` Henri Roosen
0 siblings, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-03-30 4:58 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
> >>>> Philippe Gerum wrote:
> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
> >>>>>> at the same time. Priority coupling is enabled in the kernel.
> >>>>>>
> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
> >>>>>> the switched task is run in the Linux domain. As I understand,
> >>>>>> priority coupling should prevent this.
> >>>>>>
> >>>>>> To rule out a problem in the application, this is also tested with a
> >>>>>> simple application based on the rt_print example. In my opinion, with
> >>>>>> priority coupling enabled this should print:
> >>>>>> Wakeup! - I am - awake! - Me too!
> >>>>>> But I get:
> >>>>>> Wakeup! - I am - Me too! - awake!
> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
> >>>>>>
> >>>>>> Please find attached the test application and the .config file.
> >>>>> The fine print with priority coupling is that it stops immediately
> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
> >>>>> this time debugging it, I'm pondering now whether I should keep this
> >>>>> behavior/feature in 3.x.
> >>>>>
> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
> >>>>> with traditional RTOS APIs, specifically when it comes to create
> >>>>> threads, so that high priority children do run prior to low priority
> >>>>> parents (some legacy apps may expect this). But the fact is that this
> >>>>> behavior also carries a number of uncertainties, and having the thread
> >>>>> de-boosted when blocked by Linux is a serious one.
> >>>> Maybe each thread could have a bit telling whether or not it should run
> >>>> under priority coupling, this bit would be disabled at all times, except
> >>>> during the thread creation routines, and at other times if the user
> >>>> called xnpod_set_mode to enable it if he wants?
> >>>>
> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> >>> makes sense to provide priority coupling without any mean to actually
> >>> control the impact the regular kernel may have on it.
> >>>
> >> without the irq shield you mean :-)
> >>
> >
> > No, it is not related. The issue now is with the inability to determine
> > whether and when the kernel may cause the priority boost to drop without
> > the user knowing about it.
> >
> Maybe we could add a new SIGDEBUG reason ?
>
SIGDEBUG is for detecting a misuse of some feature, the issue may be
that the feature could be a misuse of the scheduling system in itself.
This is what should be pondered before any other move.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-30 4:58 ` Philippe Gerum
@ 2011-03-30 7:30 ` Henri Roosen
2011-03-30 8:15 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Henri Roosen @ 2011-03-30 7:30 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
On Wed, Mar 30, 2011 at 6:58 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
>> >> Philippe Gerum wrote:
>> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>> >>>> Philippe Gerum wrote:
>> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>> >>>>>> at the same time. Priority coupling is enabled in the kernel.
>> >>>>>>
>> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
>> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
>> >>>>>> the switched task is run in the Linux domain. As I understand,
>> >>>>>> priority coupling should prevent this.
>> >>>>>>
>> >>>>>> To rule out a problem in the application, this is also tested with a
>> >>>>>> simple application based on the rt_print example. In my opinion, with
>> >>>>>> priority coupling enabled this should print:
>> >>>>>> Wakeup! - I am - awake! - Me too!
>> >>>>>> But I get:
>> >>>>>> Wakeup! - I am - Me too! - awake!
>> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
>> >>>>>>
>> >>>>>> Please find attached the test application and the .config file.
>> >>>>> The fine print with priority coupling is that it stops immediately
>> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
>> >>>>> this time debugging it, I'm pondering now whether I should keep this
>> >>>>> behavior/feature in 3.x.
>> >>>>>
>> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
>> >>>>> with traditional RTOS APIs, specifically when it comes to create
>> >>>>> threads, so that high priority children do run prior to low priority
>> >>>>> parents (some legacy apps may expect this). But the fact is that this
>> >>>>> behavior also carries a number of uncertainties, and having the thread
>> >>>>> de-boosted when blocked by Linux is a serious one.
>> >>>> Maybe each thread could have a bit telling whether or not it should run
>> >>>> under priority coupling, this bit would be disabled at all times, except
>> >>>> during the thread creation routines, and at other times if the user
>> >>>> called xnpod_set_mode to enable it if he wants?
>> >>>>
>> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
>> >>> makes sense to provide priority coupling without any mean to actually
>> >>> control the impact the regular kernel may have on it.
>> >>>
>> >> without the irq shield you mean :-)
>> >>
>> >
>> > No, it is not related. The issue now is with the inability to determine
>> > whether and when the kernel may cause the priority boost to drop without
>> > the user knowing about it.
>> >
>> Maybe we could add a new SIGDEBUG reason ?
>>
>
> SIGDEBUG is for detecting a misuse of some feature, the issue may be
> that the feature could be a misuse of the scheduling system in itself.
> This is what should be pondered before any other move.
>
> --
> Philippe.
>
>
>
Using a data array to track the switches and replace gettimeofday()
with sched_yield() shows the same sequence of events. Actually the
problem was shown in our main application that already uses a data
array for trace data, The rt_print based app was just for simple
reproducing the problem.
Our realtime thread should actually not do Linux system calls, neither
should it cause exceptions, but unfortunately we don't have total
control over that. So when it does make a system call we rely on
priority coupling that the task completes before the lower priority
realtime threads are scheduled. Our tracing tool shows this is not the
case.
What can I do to help fixing the priority coupling?
Thanks,
Henri.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-30 7:30 ` Henri Roosen
@ 2011-03-30 8:15 ` Philippe Gerum
2011-03-30 11:27 ` Henri Roosen
0 siblings, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-03-30 8:15 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
On Wed, 2011-03-30 at 09:30 +0200, Henri Roosen wrote:
> On Wed, Mar 30, 2011 at 6:58 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
> >> >> Philippe Gerum wrote:
> >> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
> >> >>>> Philippe Gerum wrote:
> >> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
> >> >>>>>> at the same time. Priority coupling is enabled in the kernel.
> >> >>>>>>
> >> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
> >> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
> >> >>>>>> the switched task is run in the Linux domain. As I understand,
> >> >>>>>> priority coupling should prevent this.
> >> >>>>>>
> >> >>>>>> To rule out a problem in the application, this is also tested with a
> >> >>>>>> simple application based on the rt_print example. In my opinion, with
> >> >>>>>> priority coupling enabled this should print:
> >> >>>>>> Wakeup! - I am - awake! - Me too!
> >> >>>>>> But I get:
> >> >>>>>> Wakeup! - I am - Me too! - awake!
> >> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
> >> >>>>>>
> >> >>>>>> Please find attached the test application and the .config file.
> >> >>>>> The fine print with priority coupling is that it stops immediately
> >> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
> >> >>>>> this time debugging it, I'm pondering now whether I should keep this
> >> >>>>> behavior/feature in 3.x.
> >> >>>>>
> >> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
> >> >>>>> with traditional RTOS APIs, specifically when it comes to create
> >> >>>>> threads, so that high priority children do run prior to low priority
> >> >>>>> parents (some legacy apps may expect this). But the fact is that this
> >> >>>>> behavior also carries a number of uncertainties, and having the thread
> >> >>>>> de-boosted when blocked by Linux is a serious one.
> >> >>>> Maybe each thread could have a bit telling whether or not it should run
> >> >>>> under priority coupling, this bit would be disabled at all times, except
> >> >>>> during the thread creation routines, and at other times if the user
> >> >>>> called xnpod_set_mode to enable it if he wants?
> >> >>>>
> >> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> >> >>> makes sense to provide priority coupling without any mean to actually
> >> >>> control the impact the regular kernel may have on it.
> >> >>>
> >> >> without the irq shield you mean :-)
> >> >>
> >> >
> >> > No, it is not related. The issue now is with the inability to determine
> >> > whether and when the kernel may cause the priority boost to drop without
> >> > the user knowing about it.
> >> >
> >> Maybe we could add a new SIGDEBUG reason ?
> >>
> >
> > SIGDEBUG is for detecting a misuse of some feature, the issue may be
> > that the feature could be a misuse of the scheduling system in itself.
> > This is what should be pondered before any other move.
> >
> > --
> > Philippe.
> >
> >
> >
>
> Using a data array to track the switches and replace gettimeofday()
> with sched_yield() shows the same sequence of events. Actually the
> problem was shown in our main application that already uses a data
> array for trace data, The rt_print based app was just for simple
> reproducing the problem.
>
> Our realtime thread should actually not do Linux system calls, neither
> should it cause exceptions, but unfortunately we don't have total
> control over that. So when it does make a system call we rely on
> priority coupling that the task completes before the lower priority
> realtime threads are scheduled. Our tracing tool shows this is not the
> case.
>
> What can I do to help fixing the priority coupling?
As discussed earlier, it still remains to show whether linux blocks the
task for whatever reason when issuing the syscall. In such a case, there
is not much you could do, since you would simply face a limitation of
the prio coupling design, there is no fix for this one.
I would suggest to instrument rpi_switch(), to check whether the task is
de-boosted for that reason, to make sure we are not chasing wild gooses.
>
> Thanks,
> Henri.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-30 8:15 ` Philippe Gerum
@ 2011-03-30 11:27 ` Henri Roosen
2011-03-31 13:42 ` Henri Roosen
0 siblings, 1 reply; 20+ messages in thread
From: Henri Roosen @ 2011-03-30 11:27 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
On Wed, Mar 30, 2011 at 10:15 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Wed, 2011-03-30 at 09:30 +0200, Henri Roosen wrote:
>> On Wed, Mar 30, 2011 at 6:58 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>> > On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
>> >> Philippe Gerum wrote:
>> >> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
>> >> >> Philippe Gerum wrote:
>> >> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>> >> >>>> Philippe Gerum wrote:
>> >> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>> >> >>>>>> Hi,
>> >> >>>>>>
>> >> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>> >> >>>>>> at the same time. Priority coupling is enabled in the kernel.
>> >> >>>>>>
>> >> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
>> >> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
>> >> >>>>>> the switched task is run in the Linux domain. As I understand,
>> >> >>>>>> priority coupling should prevent this.
>> >> >>>>>>
>> >> >>>>>> To rule out a problem in the application, this is also tested with a
>> >> >>>>>> simple application based on the rt_print example. In my opinion, with
>> >> >>>>>> priority coupling enabled this should print:
>> >> >>>>>> Wakeup! - I am - awake! - Me too!
>> >> >>>>>> But I get:
>> >> >>>>>> Wakeup! - I am - Me too! - awake!
>> >> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
>> >> >>>>>>
>> >> >>>>>> Please find attached the test application and the .config file.
>> >> >>>>> The fine print with priority coupling is that it stops immediately
>> >> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
>> >> >>>>> this time debugging it, I'm pondering now whether I should keep this
>> >> >>>>> behavior/feature in 3.x.
>> >> >>>>>
>> >> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
>> >> >>>>> with traditional RTOS APIs, specifically when it comes to create
>> >> >>>>> threads, so that high priority children do run prior to low priority
>> >> >>>>> parents (some legacy apps may expect this). But the fact is that this
>> >> >>>>> behavior also carries a number of uncertainties, and having the thread
>> >> >>>>> de-boosted when blocked by Linux is a serious one.
>> >> >>>> Maybe each thread could have a bit telling whether or not it should run
>> >> >>>> under priority coupling, this bit would be disabled at all times, except
>> >> >>>> during the thread creation routines, and at other times if the user
>> >> >>>> called xnpod_set_mode to enable it if he wants?
>> >> >>>>
>> >> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
>> >> >>> makes sense to provide priority coupling without any mean to actually
>> >> >>> control the impact the regular kernel may have on it.
>> >> >>>
>> >> >> without the irq shield you mean :-)
>> >> >>
>> >> >
>> >> > No, it is not related. The issue now is with the inability to determine
>> >> > whether and when the kernel may cause the priority boost to drop without
>> >> > the user knowing about it.
>> >> >
>> >> Maybe we could add a new SIGDEBUG reason ?
>> >>
>> >
>> > SIGDEBUG is for detecting a misuse of some feature, the issue may be
>> > that the feature could be a misuse of the scheduling system in itself.
>> > This is what should be pondered before any other move.
>> >
>> > --
>> > Philippe.
>> >
>> >
>> >
>>
>> Using a data array to track the switches and replace gettimeofday()
>> with sched_yield() shows the same sequence of events. Actually the
>> problem was shown in our main application that already uses a data
>> array for trace data, The rt_print based app was just for simple
>> reproducing the problem.
>>
>> Our realtime thread should actually not do Linux system calls, neither
>> should it cause exceptions, but unfortunately we don't have total
>> control over that. So when it does make a system call we rely on
>> priority coupling that the task completes before the lower priority
>> realtime threads are scheduled. Our tracing tool shows this is not the
>> case.
>>
>> What can I do to help fixing the priority coupling?
>
> As discussed earlier, it still remains to show whether linux blocks the
> task for whatever reason when issuing the syscall. In such a case, there
> is not much you could do, since you would simply face a limitation of
> the prio coupling design, there is no fix for this one.
>
> I would suggest to instrument rpi_switch(), to check whether the task is
> de-boosted for that reason, to make sure we are not chasing wild gooses.
There are 2 calls to rpi_switch each loop:
First is the switch to task 3: this is when Linux actually schedules
the task the first time for doing the system call, right?
Second is the switch to the gatekeeper: this is when the task calls
the rt_event_wait for waiting in the Xenomai domain, right?
So from the rpi_switch tracing I cannot see Linux blocking the task.
Also non of the rpi_switch calls enter the first 'if'.
What would be the thing to check next?
>
>>
>> Thanks,
>> Henri.
>
> --
> Philippe.
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-30 11:27 ` Henri Roosen
@ 2011-03-31 13:42 ` Henri Roosen
2011-03-31 14:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 20+ messages in thread
From: Henri Roosen @ 2011-03-31 13:42 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
On Wed, Mar 30, 2011 at 1:27 PM, Henri Roosen <henriroosen@domain.hid> wrote:
> On Wed, Mar 30, 2011 at 10:15 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>> On Wed, 2011-03-30 at 09:30 +0200, Henri Roosen wrote:
>>> On Wed, Mar 30, 2011 at 6:58 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>>> > On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
>>> >> Philippe Gerum wrote:
>>> >> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
>>> >> >> Philippe Gerum wrote:
>>> >> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>>> >> >>>> Philippe Gerum wrote:
>>> >> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>>> >> >>>>>> Hi,
>>> >> >>>>>>
>>> >> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>>> >> >>>>>> at the same time. Priority coupling is enabled in the kernel.
>>> >> >>>>>>
>>> >> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
>>> >> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
>>> >> >>>>>> the switched task is run in the Linux domain. As I understand,
>>> >> >>>>>> priority coupling should prevent this.
>>> >> >>>>>>
>>> >> >>>>>> To rule out a problem in the application, this is also tested with a
>>> >> >>>>>> simple application based on the rt_print example. In my opinion, with
>>> >> >>>>>> priority coupling enabled this should print:
>>> >> >>>>>> Wakeup! - I am - awake! - Me too!
>>> >> >>>>>> But I get:
>>> >> >>>>>> Wakeup! - I am - Me too! - awake!
>>> >> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
>>> >> >>>>>>
>>> >> >>>>>> Please find attached the test application and the .config file.
>>> >> >>>>> The fine print with priority coupling is that it stops immediately
>>> >> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
>>> >> >>>>> this time debugging it, I'm pondering now whether I should keep this
>>> >> >>>>> behavior/feature in 3.x.
>>> >> >>>>>
>>> >> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
>>> >> >>>>> with traditional RTOS APIs, specifically when it comes to create
>>> >> >>>>> threads, so that high priority children do run prior to low priority
>>> >> >>>>> parents (some legacy apps may expect this). But the fact is that this
>>> >> >>>>> behavior also carries a number of uncertainties, and having the thread
>>> >> >>>>> de-boosted when blocked by Linux is a serious one.
>>> >> >>>> Maybe each thread could have a bit telling whether or not it should run
>>> >> >>>> under priority coupling, this bit would be disabled at all times, except
>>> >> >>>> during the thread creation routines, and at other times if the user
>>> >> >>>> called xnpod_set_mode to enable it if he wants?
>>> >> >>>>
>>> >> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
>>> >> >>> makes sense to provide priority coupling without any mean to actually
>>> >> >>> control the impact the regular kernel may have on it.
>>> >> >>>
>>> >> >> without the irq shield you mean :-)
>>> >> >>
>>> >> >
>>> >> > No, it is not related. The issue now is with the inability to determine
>>> >> > whether and when the kernel may cause the priority boost to drop without
>>> >> > the user knowing about it.
>>> >> >
>>> >> Maybe we could add a new SIGDEBUG reason ?
>>> >>
>>> >
>>> > SIGDEBUG is for detecting a misuse of some feature, the issue may be
>>> > that the feature could be a misuse of the scheduling system in itself.
>>> > This is what should be pondered before any other move.
>>> >
>>> > --
>>> > Philippe.
>>> >
>>> >
>>> >
>>>
>>> Using a data array to track the switches and replace gettimeofday()
>>> with sched_yield() shows the same sequence of events. Actually the
>>> problem was shown in our main application that already uses a data
>>> array for trace data, The rt_print based app was just for simple
>>> reproducing the problem.
>>>
>>> Our realtime thread should actually not do Linux system calls, neither
>>> should it cause exceptions, but unfortunately we don't have total
>>> control over that. So when it does make a system call we rely on
>>> priority coupling that the task completes before the lower priority
>>> realtime threads are scheduled. Our tracing tool shows this is not the
>>> case.
>>>
>>> What can I do to help fixing the priority coupling?
>>
>> As discussed earlier, it still remains to show whether linux blocks the
>> task for whatever reason when issuing the syscall. In such a case, there
>> is not much you could do, since you would simply face a limitation of
>> the prio coupling design, there is no fix for this one.
>>
>> I would suggest to instrument rpi_switch(), to check whether the task is
>> de-boosted for that reason, to make sure we are not chasing wild gooses.
>
> There are 2 calls to rpi_switch each loop:
> First is the switch to task 3: this is when Linux actually schedules
> the task the first time for doing the system call, right?
> Second is the switch to the gatekeeper: this is when the task calls
> the rt_event_wait for waiting in the Xenomai domain, right?
>
> So from the rpi_switch tracing I cannot see Linux blocking the task.
> Also non of the rpi_switch calls enter the first 'if'.
>
> What would be the thing to check next?
>
>>
>>>
>>> Thanks,
>>> Henri.
>>
>> --
>> Philippe.
>>
>>
>>
>
Did some more tracing to see why the lower priority thread is
scheduled before the higher prio thread is ended.
The highest priority task makes a system call and gets relaxed by
xnshadow_relax. The rpi is pushed here and a Linux call with
LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
ROOT task. So far so good!
In the Linux domain, we run into the lostage_handler, where the
scheduled LO_WAKEUP_REQ is executed. Here there is a call to
xnpod_schedule() which actually causes a switch back to the primary
domain and the lower priority Xenomai task to be scheduled in, even
before the wanted process is woken up.
Now, I am unsure what is faulty here and maybe Philippe or someone can
answer that. Personally I would have expected the xnpod_schedule (or
xnsched_pick_next) to know about the rpi list and not schedule a lower
priority task than of any on that list. I was unable to find such
code.
A quick and dirty test of commenting out the xnpod_schedule() call at
LO_WAKEUP_REQ makes my test application show the correct sequence of
events, but that cannot be the fix...
Anyone any suggestions?
Thanks,
Henri
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-31 13:42 ` Henri Roosen
@ 2011-03-31 14:28 ` Gilles Chanteperdrix
2011-03-31 14:44 ` Henri Roosen
2011-03-31 14:50 ` Gilles Chanteperdrix
0 siblings, 2 replies; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-31 14:28 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
Henri Roosen wrote:
> Did some more tracing to see why the lower priority thread is
> scheduled before the higher prio thread is ended.
>
> The highest priority task makes a system call and gets relaxed by
> xnshadow_relax. The rpi is pushed here and a Linux call with
> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
> ROOT task. So far so good!
>
> In the Linux domain, we run into the lostage_handler, where the
> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
> xnpod_schedule() which actually causes a switch back to the primary
> domain and the lower priority Xenomai task to be scheduled in, even
> before the wanted process is woken up.
>
> Now, I am unsure what is faulty here and maybe Philippe or someone can
> answer that. Personally I would have expected the xnpod_schedule (or
> xnsched_pick_next) to know about the rpi list and not schedule a lower
> priority task than of any on that list. I was unable to find such
> code.
>
Unless I am wrong, what happens is whait is intended, at least if we
read the comment:
case LO_WAKEUP_REQ:
/*
* We need to downgrade the root thread
* priority whenever the APC runs over a
* non-shadow, so that the temporary boost we
* applied in xnshadow_relax() is not
* spuriously inherited by the latter until
* the relaxed shadow actually resumes in
* secondary mode.
*/
rpi_clear_local(xnshadow_thread(current));
xnpod_schedule();
Which means that we do not want other Linux kernel code than the
real-time thread itself to inherit from this thread priority. Except
that all the code from the switch to root thread to the lostage_handler
(which means any Linux currently preempted critical section) already
inherited the priority.
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-31 14:28 ` Gilles Chanteperdrix
@ 2011-03-31 14:44 ` Henri Roosen
2011-03-31 14:50 ` Gilles Chanteperdrix
1 sibling, 0 replies; 20+ messages in thread
From: Henri Roosen @ 2011-03-31 14:44 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, Mar 31, 2011 at 4:28 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Henri Roosen wrote:
>> Did some more tracing to see why the lower priority thread is
>> scheduled before the higher prio thread is ended.
>>
>> The highest priority task makes a system call and gets relaxed by
>> xnshadow_relax. The rpi is pushed here and a Linux call with
>> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
>> ROOT task. So far so good!
>>
>> In the Linux domain, we run into the lostage_handler, where the
>> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
>> xnpod_schedule() which actually causes a switch back to the primary
>> domain and the lower priority Xenomai task to be scheduled in, even
>> before the wanted process is woken up.
>>
>> Now, I am unsure what is faulty here and maybe Philippe or someone can
>> answer that. Personally I would have expected the xnpod_schedule (or
>> xnsched_pick_next) to know about the rpi list and not schedule a lower
>> priority task than of any on that list. I was unable to find such
>> code.
>>
>
> Unless I am wrong, what happens is whait is intended, at least if we
> read the comment:
> case LO_WAKEUP_REQ:
> /*
> * We need to downgrade the root thread
> * priority whenever the APC runs over a
> * non-shadow, so that the temporary boost we
> * applied in xnshadow_relax() is not
> * spuriously inherited by the latter until
> * the relaxed shadow actually resumes in
> * secondary mode.
> */
> rpi_clear_local(xnshadow_thread(current));
> xnpod_schedule();
>
> Which means that we do not want other Linux kernel code than the
> real-time thread itself to inherit from this thread priority. Except
> that all the code from the switch to root thread to the lostage_handler
> (which means any Linux currently preempted critical section) already
> inherited the priority.
>
> --
> Gilles.
>
Yes, I think too that what is coded here might be what is intended.
Except the behavior that exactly at this xnpod_schedule() call the
lower priority threads from the primary domain are scheduled in, while
Priority Coupling promises to not schedule any of those before the
higher priority relaxed thread. That is why I'm wondering where that
specific code is, which I would expect somewhere down the line of
xnpod_schedule() which would peek the rpi list or so. Or is it my
misunderstanding to expect such code?
Thanks,
Henri
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-31 14:28 ` Gilles Chanteperdrix
2011-03-31 14:44 ` Henri Roosen
@ 2011-03-31 14:50 ` Gilles Chanteperdrix
2011-04-01 9:36 ` Henri Roosen
1 sibling, 1 reply; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-03-31 14:50 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
Gilles Chanteperdrix wrote:
> Henri Roosen wrote:
>> Did some more tracing to see why the lower priority thread is
>> scheduled before the higher prio thread is ended.
>>
>> The highest priority task makes a system call and gets relaxed by
>> xnshadow_relax. The rpi is pushed here and a Linux call with
>> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
>> ROOT task. So far so good!
>>
>> In the Linux domain, we run into the lostage_handler, where the
>> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
>> xnpod_schedule() which actually causes a switch back to the primary
>> domain and the lower priority Xenomai task to be scheduled in, even
>> before the wanted process is woken up.
>>
>> Now, I am unsure what is faulty here and maybe Philippe or someone can
>> answer that. Personally I would have expected the xnpod_schedule (or
>> xnsched_pick_next) to know about the rpi list and not schedule a lower
>> priority task than of any on that list. I was unable to find such
>> code.
>>
>
> Unless I am wrong, what happens is whait is intended, at least if we
> read the comment:
> case LO_WAKEUP_REQ:
> /*
> * We need to downgrade the root thread
> * priority whenever the APC runs over a
> * non-shadow, so that the temporary boost we
> * applied in xnshadow_relax() is not
> * spuriously inherited by the latter until
> * the relaxed shadow actually resumes in
> * secondary mode.
> */
> rpi_clear_local(xnshadow_thread(current));
> xnpod_schedule();
>
> Which means that we do not want other Linux kernel code than the
> real-time thread itself to inherit from this thread priority. Except
> that all the code from the switch to root thread to the lostage_handler
> (which means any Linux currently preempted critical section) already
> inherited the priority.
The problem is that calling wake_up_process (a bit below that code) does
not guarantee that the next thread scheduled is the shadow running in
secondary mode. There may be other Linux threads with higher priorities,
and we do not want them to inherit this priority. The idea is that if
the next process scheduled is indeed the real-time shadow running in
secondary mode, the RPI will be applied in do_schedule_event. But of
course, this leaves a window for another real-time thread to preempt. At
least it is the way I would understand this, but I am not sure I
understand RPI all that well, so, I will shut up and let Philippe answer.
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-03-31 14:50 ` Gilles Chanteperdrix
@ 2011-04-01 9:36 ` Henri Roosen
2011-04-01 9:44 ` Gilles Chanteperdrix
2011-04-01 11:20 ` Philippe Gerum
0 siblings, 2 replies; 20+ messages in thread
From: Henri Roosen @ 2011-04-01 9:36 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, Mar 31, 2011 at 4:50 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Gilles Chanteperdrix wrote:
>> Henri Roosen wrote:
>>> Did some more tracing to see why the lower priority thread is
>>> scheduled before the higher prio thread is ended.
>>>
>>> The highest priority task makes a system call and gets relaxed by
>>> xnshadow_relax. The rpi is pushed here and a Linux call with
>>> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
>>> ROOT task. So far so good!
>>>
>>> In the Linux domain, we run into the lostage_handler, where the
>>> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
>>> xnpod_schedule() which actually causes a switch back to the primary
>>> domain and the lower priority Xenomai task to be scheduled in, even
>>> before the wanted process is woken up.
>>>
>>> Now, I am unsure what is faulty here and maybe Philippe or someone can
>>> answer that. Personally I would have expected the xnpod_schedule (or
>>> xnsched_pick_next) to know about the rpi list and not schedule a lower
>>> priority task than of any on that list. I was unable to find such
>>> code.
>>>
>>
>> Unless I am wrong, what happens is whait is intended, at least if we
>> read the comment:
>> case LO_WAKEUP_REQ:
>> /*
>> * We need to downgrade the root thread
>> * priority whenever the APC runs over a
>> * non-shadow, so that the temporary boost we
>> * applied in xnshadow_relax() is not
>> * spuriously inherited by the latter until
>> * the relaxed shadow actually resumes in
>> * secondary mode.
>> */
>> rpi_clear_local(xnshadow_thread(current));
>> xnpod_schedule();
>>
>> Which means that we do not want other Linux kernel code than the
>> real-time thread itself to inherit from this thread priority. Except
>> that all the code from the switch to root thread to the lostage_handler
>> (which means any Linux currently preempted critical section) already
>> inherited the priority.
>
> The problem is that calling wake_up_process (a bit below that code) does
> not guarantee that the next thread scheduled is the shadow running in
> secondary mode. There may be other Linux threads with higher priorities,
> and we do not want them to inherit this priority. The idea is that if
> the next process scheduled is indeed the real-time shadow running in
> secondary mode, the RPI will be applied in do_schedule_event. But of
> course, this leaves a window for another real-time thread to preempt. At
> least it is the way I would understand this, but I am not sure I
> understand RPI all that well, so, I will shut up and let Philippe answer.
>
> --
> Gilles.
>
Thanks Gilles for your input. This Priority Coupling stuff is a little
complex and input about the corner cases is always welcome and
helpful!
I did a little more tests with xnpod_schedule() commented out on
LO_WAKEUP_REQ. Scheduling shows as expected to me: the lower and level
primary tasks don't interrupt the migrated thread while higher
priority tasks do interrupt that task. I have not seen any deadlocks
yet or ran into corner cases, but of course I don't know all.
Now, looking back in the history of shadow.c I see that
xnpod_schedule() was introduced when the xnsched_renice_root() was
introduced, which is now part of rpi_clear_local. In my point of view,
the xnpod_schedule() call is only needed when the
xnsched_renice_root() has been done, so should be moved inside the if
of rpi_clear_local. But again, it is my point of view and don't know
all the corner cases.
In our case the scheduled task after the switch to secondary is
actually mostly the IDLE task, thus calling the xnsched_renice_root
and xnpod_schedule() for doing exactly that what is in the comment. So
my main question remains: is the call to xnpod_schedule really needed
here after xnsched_renice_root()? And if so, why doesn't the
xnpod_schedule not take the priorities on the rpi list into account?
Thanks,
Henri.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-04-01 9:36 ` Henri Roosen
@ 2011-04-01 9:44 ` Gilles Chanteperdrix
2011-04-01 11:20 ` Philippe Gerum
1 sibling, 0 replies; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-04-01 9:44 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
Henri Roosen wrote:
>
> Thanks Gilles for your input. This Priority Coupling stuff is a little
> complex and input about the corner cases is always welcome and
> helpful!
>
> I did a little more tests with xnpod_schedule() commented out on
> LO_WAKEUP_REQ. Scheduling shows as expected to me: the lower and level
> primary tasks don't interrupt the migrated thread while higher
> priority tasks do interrupt that task. I have not seen any deadlocks
> yet or ran into corner cases, but of course I don't know all.
>
> Now, looking back in the history of shadow.c I see that
> xnpod_schedule() was introduced when the xnsched_renice_root() was
> introduced, which is now part of rpi_clear_local. In my point of view,
> the xnpod_schedule() call is only needed when the
> xnsched_renice_root() has been done, so should be moved inside the if
> of rpi_clear_local. But again, it is my point of view and don't know
> all the corner cases.
>
> In our case the scheduled task after the switch to secondary is
> actually mostly the IDLE task, thus calling the xnsched_renice_root
> and xnpod_schedule() for doing exactly that what is in the comment. So
> my main question remains: is the call to xnpod_schedule really needed
> here after xnsched_renice_root()? And if so, why doesn't the
> xnpod_schedule not take the priorities on the rpi list into account?
The current task when entering LO_WAKEUP_REQ is not a Xenomai task, so,
rip_clear_local disables the boost. At this point we have no guarantee
that "p" will be the next task scheduled, or that the next call to
schedule will schedule another task at all, so that we will pass by
do_schedule_event.
There may be a way to avoid this, but removing xnpod_schedule() is
certainly not it. Imagine that when we enter LO_WAKEUP_REQ, current is a
Linux real-time task with a higher priority than the Xenomai task, the
root thread will be unduly boosted until the moment where that task is
suspended and the Xenomai task can be at last scheduled. This would be a
plain sort of priority inversion.
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-04-01 9:36 ` Henri Roosen
2011-04-01 9:44 ` Gilles Chanteperdrix
@ 2011-04-01 11:20 ` Philippe Gerum
2011-04-01 11:37 ` Gilles Chanteperdrix
1 sibling, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2011-04-01 11:20 UTC (permalink / raw)
To: Henri Roosen; +Cc: xenomai
On Fri, 2011-04-01 at 11:36 +0200, Henri Roosen wrote:
> On Thu, Mar 31, 2011 at 4:50 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > Gilles Chanteperdrix wrote:
> >> Henri Roosen wrote:
> >>> Did some more tracing to see why the lower priority thread is
> >>> scheduled before the higher prio thread is ended.
> >>>
> >>> The highest priority task makes a system call and gets relaxed by
> >>> xnshadow_relax. The rpi is pushed here and a Linux call with
> >>> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
> >>> ROOT task. So far so good!
> >>>
> >>> In the Linux domain, we run into the lostage_handler, where the
> >>> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
> >>> xnpod_schedule() which actually causes a switch back to the primary
> >>> domain and the lower priority Xenomai task to be scheduled in, even
> >>> before the wanted process is woken up.
> >>>
> >>> Now, I am unsure what is faulty here and maybe Philippe or someone can
> >>> answer that. Personally I would have expected the xnpod_schedule (or
> >>> xnsched_pick_next) to know about the rpi list and not schedule a lower
> >>> priority task than of any on that list. I was unable to find such
> >>> code.
> >>>
> >>
> >> Unless I am wrong, what happens is whait is intended, at least if we
> >> read the comment:
> >> case LO_WAKEUP_REQ:
> >> /*
> >> * We need to downgrade the root thread
> >> * priority whenever the APC runs over a
> >> * non-shadow, so that the temporary boost we
> >> * applied in xnshadow_relax() is not
> >> * spuriously inherited by the latter until
> >> * the relaxed shadow actually resumes in
> >> * secondary mode.
> >> */
> >> rpi_clear_local(xnshadow_thread(current));
> >> xnpod_schedule();
> >>
> >> Which means that we do not want other Linux kernel code than the
> >> real-time thread itself to inherit from this thread priority. Except
> >> that all the code from the switch to root thread to the lostage_handler
> >> (which means any Linux currently preempted critical section) already
> >> inherited the priority.
> >
> > The problem is that calling wake_up_process (a bit below that code) does
> > not guarantee that the next thread scheduled is the shadow running in
> > secondary mode. There may be other Linux threads with higher priorities,
> > and we do not want them to inherit this priority. The idea is that if
> > the next process scheduled is indeed the real-time shadow running in
> > secondary mode, the RPI will be applied in do_schedule_event. But of
> > course, this leaves a window for another real-time thread to preempt. At
> > least it is the way I would understand this, but I am not sure I
> > understand RPI all that well, so, I will shut up and let Philippe answer.
> >
> > --
> > Gilles.
> >
>
> Thanks Gilles for your input. This Priority Coupling stuff is a little
> complex and input about the corner cases is always welcome and
> helpful!
>
> I did a little more tests with xnpod_schedule() commented out on
> LO_WAKEUP_REQ. Scheduling shows as expected to me: the lower and level
> primary tasks don't interrupt the migrated thread while higher
> priority tasks do interrupt that task. I have not seen any deadlocks
> yet or ran into corner cases, but of course I don't know all.
>
> Now, looking back in the history of shadow.c I see that
> xnpod_schedule() was introduced when the xnsched_renice_root() was
> introduced, which is now part of rpi_clear_local. In my point of view,
> the xnpod_schedule() call is only needed when the
> xnsched_renice_root() has been done, so should be moved inside the if
> of rpi_clear_local. But again, it is my point of view and don't know
> all the corner cases.
>
Correct, but the extraneous xnpod_schedule() in case no de-boost took
place is a minor point. If the scheduler state did not change (no
de-boost), then it will lead to a cheap nop (only a bitop test). If it
has changed, it must be applied right after, because you just don't want
the reality to contradict what your scheduler state says.
Besides, if any interrupt is taken after rpi_clear_local(), the
rescheduling procedure will be called on the interrupt return path,
enforcing the new state anyway. So delaying the call to xnpod_schedule()
is not an option in any case.
> In our case the scheduled task after the switch to secondary is
> actually mostly the IDLE task, thus calling the xnsched_renice_root
> and xnpod_schedule() for doing exactly that what is in the comment. So
> my main question remains: is the call to xnpod_schedule really needed
> here after xnsched_renice_root()? And if so, why doesn't the
> xnpod_schedule not take the priorities on the rpi list into account?
No, xnpod_schedule() does what RPI wants already, and RPI wants a
temporary de-boosting of the root thread to avoid a really bad priority
inversion between the rt and non-rt domains, without affecting the RPI
settings permanently, which shall be applied anew as soon as they stop
causing a rt vs non-rt priority inversion.
Step back, and reconsider the logic:
1- RPI says "linux should be boosted when a shadow is migrated to
secondary mode, to avoid priority inversion between two xenomai threads
running in different domains".
2- xenomai says "linux should not be allowed to benefit from a boosted
priority unless it is actually running one of my relaxed threads, to
avoid priority inversion between rt and non-rt activity"
3- linux says "I do apply my own scheduling logic and priorities"
- xenomai attempts to provide #1 with the RPI scheme
- xenomai enforces #2 with rpi_clear_local().
- wake_up_process() as called by the APC handler enforces #3
Your issue all comes from the fact that #3 may well contradict #1
sometimes. And when a different non-xenomai thread is resumed by linux
prior to the relaxing one, xenomai _has to_ apply rule #2. See Gilles's
explanation for this, it is 100% to the point. If you don't do this, you
could end up with a real-time activity potentially blocked by a non
real-time one for an indefinite amount of time. And that would be much
worse than allowing a temporary priority inversion only affecting a
real-time thread which left the real-time domain willingly.
This is why rule #2 will always have precedence over expectation #1, you
just hit a limitation of the RPI scheme. It is a best effort mechanism,
limited by the fact that we can't tell linux to refrain from applying
its own scheduling rules when running within its own domain -- fair
enough.
Hence my initial comment you may want to read again: maybe the RPI is
broken by design, not in its current implementation which actually does
as much as it can to mitigate conflicts, but cannot always succeed. For
that reason, maybe RPI might even go away in the next xenomai
architecture, if it keeps on misleading people, I'm exactly pondering
that decision (*).
And yes, RPI tends to be really complex. Which makes it suspicious, even
for me now.
(*) Unless I find a way to direct the linux scheduler to the "right"
task in the migration case, but so far, I found none (none that would be
sane, I mean).
>
> Thanks,
> Henri.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-04-01 11:20 ` Philippe Gerum
@ 2011-04-01 11:37 ` Gilles Chanteperdrix
2011-04-01 13:07 ` Henri Roosen
0 siblings, 1 reply; 20+ messages in thread
From: Gilles Chanteperdrix @ 2011-04-01 11:37 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> (*) Unless I find a way to direct the linux scheduler to the "right"
> task in the migration case, but so far, I found none (none that would be
> sane, I mean).
In Henri particular case. Maybe there would be a way to call
wake_up_process first, then look into the (Linux) scheduler state, see
if a reschedule is pending. If a reschedule is pending, do not clear the
boost and let do_schedule_event handle the situation? Otherwise, clear
the boost.
Or maybe that fits into the "insane" category?
--
Gilles.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xenomai-help] Priority coupling broken?
2011-04-01 11:37 ` Gilles Chanteperdrix
@ 2011-04-01 13:07 ` Henri Roosen
0 siblings, 0 replies; 20+ messages in thread
From: Henri Roosen @ 2011-04-01 13:07 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, Apr 1, 2011 at 1:37 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Philippe Gerum wrote:
>> (*) Unless I find a way to direct the linux scheduler to the "right"
>> task in the migration case, but so far, I found none (none that would be
>> sane, I mean).
>
> In Henri particular case. Maybe there would be a way to call
> wake_up_process first, then look into the (Linux) scheduler state, see
> if a reschedule is pending. If a reschedule is pending, do not clear the
> boost and let do_schedule_event handle the situation? Otherwise, clear
> the boost.
>
> Or maybe that fits into the "insane" category?
>
> --
> Gilles.
>
Thanks Philippe and Gilles! Your detailed explanation brings the
pieces of the puzzle together! I understand why the reschedule is
needed there. And that indeed Priority coupling is broken by design
then: most likely the thread running in the Linux domain at the time a
Xenomai thread is relaxed is not a Xenomai thread. The reschedule will
then always schedule any runnable Xenomai task before the relaxed
thread in Linux domain.
Priority coupling can never guarantee rule #1, also because a Linux
call might block.
However, it would be great to find a way to direct the Linux
scheduler, maybe the way Gilles proposed. Then at least rule #1 would
be valid until the relaxed task blocks or reschedules... but of course
will never be guaranteed..
Kind regards,
Henri.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-04-01 13:07 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-29 14:41 [Xenomai-help] Priority coupling broken? Henri Roosen
2011-03-29 15:28 ` Philippe Gerum
2011-03-29 19:11 ` Gilles Chanteperdrix
2011-03-29 19:17 ` Philippe Gerum
2011-03-29 19:19 ` Gilles Chanteperdrix
2011-03-29 19:27 ` Philippe Gerum
2011-03-29 19:29 ` Gilles Chanteperdrix
2011-03-30 4:58 ` Philippe Gerum
2011-03-30 7:30 ` Henri Roosen
2011-03-30 8:15 ` Philippe Gerum
2011-03-30 11:27 ` Henri Roosen
2011-03-31 13:42 ` Henri Roosen
2011-03-31 14:28 ` Gilles Chanteperdrix
2011-03-31 14:44 ` Henri Roosen
2011-03-31 14:50 ` Gilles Chanteperdrix
2011-04-01 9:36 ` Henri Roosen
2011-04-01 9:44 ` Gilles Chanteperdrix
2011-04-01 11:20 ` Philippe Gerum
2011-04-01 11:37 ` Gilles Chanteperdrix
2011-04-01 13:07 ` Henri Roosen
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.