linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Changing Kernel thread priorities
       [not found] ` <17185480.5304.1307435255996.JavaMail.root@WARSBL214.highway.te lekom.at>
@ 2011-06-07  8:32   ` Monica Puig-Pey
  2011-06-07  8:43     ` Thomas Gleixner
  0 siblings, 1 reply; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-07  8:32 UTC (permalink / raw)
  To: hannes_bauer
  Cc: Peter Zijlstra, Rolando Martins, linux-rt-users, linux-kernel, tglx

El 07/06/11 10:27, Johannes Bauer escribió:
> Absolutly correct!
>
> However, if you are running the system on an embedded platform, where the _WHOLE_ system (including priorities) is preconfigured and never touched, starting a irq thread with the right prio from start is a more straightforward method than having to invoke a script that changes it using userspace chrt tool.
>
> Regards JB
> ----- Ursprüngliche Nachricht -----
> Von: "Peter Zijlstra"<peterz@infradead.org>
> Erhalten: 07.06.2011 00:36
> An: hannes_bauer@aon.at
>
> "Monica Puig-Pey" wrote:
>>
>> I need to change the priority from inside the driver, when creating the
>> kernel thread.
>
> No you don't. How does you driver know about what priority is correct
> wrt all the other running RT tasks on the system?
>
> Determining the right priority in a fixed priority scheduling system is
> a system wide problem, nobody but the administrator can possibly even
> begin to solve it.
>
> There's a reason all RT irq threads are started at 50, its plain
> impossible to do better.
>

That's it!
If I work with embedded system where I know all my tasks running and 
there is not a user how could I do it?

What I tried is create the kernel thread in my init_module using:

	#include <linux/kthread.h>

	struct task_struct *kthread_create(int (*threadfn)(void *data),
				   void *data,
				   const char namefmt[], ...)
and then running it with:

	#include <linux/sched.h>
	
	extern int wake_up_process(struct task_struct *tsk);

These functions stars a Kthread which has a NON RT priority. I can see 
this using the ps command from user space.
Because it's not a real time thread is why I want, better need, to 
change its priority, to have only real time threads running in my 
driver. I want to use the Kthread as a bottom half for the interrupts.

How could I create real time kernel threads then? is kthread_create 
wrong for real time enviroment?


-- 
__________________________________________________________________________________

Mónica Puig-Pey González       E-mail: puigpeym@unican.es

Grupo de Computadores y Tiempo Real, Departamento de Electrónica y 
Computadores.
Facultad de Ciencias - Universidad de Cantabria
Av. de los Castros s/n. 39005 - Santander, España
__________________________________________________________________________________

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

* Re: Changing Kernel thread priorities
  2011-06-07  8:32   ` Changing Kernel thread priorities Monica Puig-Pey
@ 2011-06-07  8:43     ` Thomas Gleixner
  2011-06-07 21:28       ` Threaded Irqs (was "Changing Kernel thread priorities") Tim Sander
  0 siblings, 1 reply; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-07  8:43 UTC (permalink / raw)
  To: Monica Puig-Pey
  Cc: hannes_bauer, Peter Zijlstra, Rolando Martins, linux-rt-users,
	linux-kernel

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

On Tue, 7 Jun 2011, Monica Puig-Pey wrote:
> El 07/06/11 10:27, Johannes Bauer escribió:
> > There's a reason all RT irq threads are started at 50, its plain
> > impossible to do better.
> > 
> 
> That's it!
> If I work with embedded system where I know all my tasks running and there is
> not a user how could I do it?

init scripts run from user space and you can adjust the priority there.
 
> What I tried is create the kernel thread in my init_module using:
> 
> 	#include <linux/kthread.h>
> 
> 	struct task_struct *kthread_create(int (*threadfn)(void *data),
> 				   void *data,
> 				   const char namefmt[], ...)
> and then running it with:
> 
> 	#include <linux/sched.h>
> 	
> 	extern int wake_up_process(struct task_struct *tsk);
> 
> These functions stars a Kthread which has a NON RT priority. I can see this
> using the ps command from user space.
> Because it's not a real time thread is why I want, better need, to change its
> priority, to have only real time threads running in my driver. I want to use
> the Kthread as a bottom half for the interrupts.

Use threaded interrupt handlers. That's what they are made for.

Thanks,

	tglx

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

* Threaded Irqs (was "Changing Kernel thread priorities")
  2011-06-07  8:43     ` Thomas Gleixner
@ 2011-06-07 21:28       ` Tim Sander
  2011-06-07 21:56         ` Thomas Gleixner
  0 siblings, 1 reply; 33+ messages in thread
From: Tim Sander @ 2011-06-07 21:28 UTC (permalink / raw)
  To: Thomas Gleixner, linux-rt-users; +Cc: linux-kernel

[-- Attachment #1: Type: Text/Plain, Size: 1713 bytes --]

Hi Thomas and all preempt RT interested

> Use threaded interrupt handlers. That's what they are made for.
I just started using threaded interrupt handlers in 2.6.39 for an
arm system (pcm043 - arm1136jfs). The results where not so good as
i expected. I set the rt prio of the interrupt to 99 (the scheduling 
type made difference since it was the only interrupt at this level). 
The user io driver for this where set to 98. I hadn't instrumented 
the irqthread but the latencies where to high for our buffer which 
can hold data for about 400µs. After configuring the IRQ as 
non-threaded, but still using threaded irqs the latencies where fast
enough for the mentioned buffer size.

Nevertheless are there still scheduling latencies for the usermode
handler thread which then runs at rt prio 99 for about 1ms. I know
this is not an preempt-rt kernel but i hoped to get better values out
of this configuration. 

So if anybody has an idea how to get better latencies out of a 2.6.39
kernel, please let me know.

I triead SLAB and SLOB allocator and they didn't made any difference for me.

Best regards
Tim

PS: i patched the kernel to get threadedirqs with:

diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
index 4e05237..28ae32c 100644
--- a/arch/arm/mach-mx3/Kconfig
+++ b/arch/arm/mach-mx3/Kconfig
@@ -162,6 +162,7 @@ config MACH_PCM043
        select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
        select IMX_HAVE_PLATFORM_SPI_IMX
        select MXC_ULPI if USB_ULPI
+       select IRQ_FORCED_THREADING
        help
          Include support for Phytec pcm043 platform. This includes
          specific configurations for the board and its peripherals.

[-- Attachment #2: 2.6.39_kernelconfig_pcm043 --]
[-- Type: text/plain, Size: 44524 bytes --]

#
# Automatically generated make config: don't edit
# Linux/arm 2.6.39 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_HAVE_PWM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_SCHED_CLOCK=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_LZO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_FORCED_THREADING=y
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
# CONFIG_TREE_PREEMPT_RCU is not set
CONFIG_TINY_RCU=y
# CONFIG_TINY_PREEMPT_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=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_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_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
CONFIG_ARCH_MXC=y
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_STMP3XXX is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_NUC93X is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5P6442 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS4 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_TCC_926 is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
CONFIG_GPIO_PCA953X=m
# CONFIG_KEYBOARD_GPIO_POLLED is not set
CONFIG_IMX_HAVE_PLATFORM_FEC=y
CONFIG_IMX_HAVE_PLATFORM_FLEXCAN=y
CONFIG_IMX_HAVE_PLATFORM_FSL_USB2_UDC=y
CONFIG_IMX_HAVE_PLATFORM_IMX2_WDT=y
CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y
CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y
CONFIG_IMX_HAVE_PLATFORM_IMX_UART=y
CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI=y
CONFIG_IMX_HAVE_PLATFORM_MXC_NAND=y
CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX=y
CONFIG_IMX_HAVE_PLATFORM_SPI_IMX=y

#
# Freescale MXC Implementations
#
# CONFIG_ARCH_MX1 is not set
# CONFIG_ARCH_MX2 is not set
# CONFIG_ARCH_MX25 is not set
CONFIG_ARCH_MX3=y
# CONFIG_ARCH_MXC91231 is not set
# CONFIG_ARCH_MX5 is not set
CONFIG_ARCH_MX35=y
CONFIG_SOC_IMX35=y

#
# MX3 platforms:
#
# CONFIG_MACH_MX31ADS is not set
# CONFIG_MACH_PCM037 is not set
# CONFIG_MACH_MX31LITE is not set
# CONFIG_MACH_MX31_3DS is not set
# CONFIG_MACH_MX31MOBOARD is not set
# CONFIG_MACH_MX31LILLY is not set
# CONFIG_MACH_QONG is not set
CONFIG_MACH_PCM043=y
# CONFIG_MACH_ARMADILLO5X0 is not set
# CONFIG_MACH_MX35_3DS is not set
# CONFIG_MACH_KZM_ARM11_01 is not set
# CONFIG_MACH_BUG is not set
# CONFIG_MACH_EUKREA_CPUIMX35 is not set
# CONFIG_MACH_VPR200 is not set
# CONFIG_MXC_IRQ_PRIOR is not set
CONFIG_MXC_AVIC=y
CONFIG_MXC_PWM=y
# CONFIG_MXC_DEBUG_BOARD is not set
CONFIG_HAVE_EPIT=y
CONFIG_MXC_USE_EPIT=y
CONFIG_MXC_ULPI=y
CONFIG_ARCH_MXC_IOMUX_V3=y
CONFIG_ARCH_MXC_AUDMUX_V2=y

#
# System MMU
#

#
# Processor Type
#
CONFIG_CPU_V6=y
CONFIG_CPU_32v6=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_CPU_HAS_PMU=y
# CONFIG_ARM_ERRATA_411920 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_PL310_ERRATA_727915 is not set

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_NEED_PER_CPU_KM=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=ttymxc0,115200n8 quiet"
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_VFP=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
CONFIG_CAN=y
CONFIG_CAN_RAW=y
CONFIG_CAN_BCM=y

#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=y
CONFIG_CAN_CALC_BITTIMING=y
# CONFIG_CAN_MCP251X is not set
CONFIG_HAVE_CAN_FLEXCAN=y
CONFIG_CAN_FLEXCAN=y
# CONFIG_CAN_SJA1000 is not set
# CONFIG_CAN_C_CAN is not set

#
# CAN USB interfaces
#
# CONFIG_CAN_EMS_USB is not set
# CONFIG_CAN_ESD_USB2 is not set
# CONFIG_CAN_SOFTING is not set
# CONFIG_CAN_DEBUG_DEVICES is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_TESTS is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

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

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

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
# CONFIG_MTD_ARM_INTEGRATOR is not set
CONFIG_MTD_PLATRAM=m

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

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND_ECC=m
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=m
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_NAND_MXC=m
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_MISC_DEVICES=y
# CONFIG_AD525X_DPOT is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS 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=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
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 is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_MII 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_BCM63XX_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_MICREL_PHY=y
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
# CONFIG_AX88796 is not set
# CONFIG_SMC91X is not set
# CONFIG_DM9000 is not set
# CONFIG_ENC28J60 is not set
# CONFIG_ETHOC is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_DNET 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_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_FEC=y
# CONFIG_FTMAC100 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_WAN is not set

#
# CAIF transport drivers
#
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=m
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
CONFIG_INPUT_SPARSEKMAP=m

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

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_IMX is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_AMBAKMI is not set
CONFIG_SERIO_LIBPS2=m
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX3107 is not set
CONFIG_SERIAL_IMX=y
CONFIG_SERIAL_IMX_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_IMX=m
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=y
# CONFIG_SPI_GPIO is not set
CONFIG_SPI_IMX_VER_0_7=y
CONFIG_SPI_IMX=y
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
CONFIG_SPI_SPIDEV=y
# CONFIG_SPI_TLE62X0 is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO expanders:
#
# CONFIG_GPIO_BASIC_MMIO is not set
# CONFIG_GPIO_IT8761E is not set
# CONFIG_GPIO_PL061 is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
CONFIG_W1=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS2482 is not set
CONFIG_W1_MASTER_MXC=y
# CONFIG_W1_MASTER_DS1WM is not set
# CONFIG_W1_MASTER_GPIO is not set

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
# CONFIG_W1_SLAVE_DS2423 is not set
CONFIG_W1_SLAVE_DS2431=m
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=m
CONFIG_W1_SLAVE_BQ27000=m
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
CONFIG_IMX2_WDT=y

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_MFD_SUPPORT=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set

#
# Special HID drivers
#
# CONFIG_HID_3M_PCT is not set
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CANDO 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_EMS_FF is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MOSART is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_QUANTA is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_ROCCAT_ARVO is not set
# CONFIG_HID_ROCCAT_KONE is not set
# CONFIG_HID_ROCCAT_KONEPLUS is not set
# CONFIG_HID_ROCCAT_KOVAPLUS is not set
# CONFIG_HID_ROCCAT_PYRA is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_STANTUM 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_HID_ZYDACRON is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB_ARCH_HAS_OHCI is not set
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_DYNAMIC_MINORS=y
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB 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=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_MXC=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set
# CONFIG_USB_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_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
# CONFIG_USB_UAS is not set
# CONFIG_USB_LIBUSUAL is not set

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

#
# USB port drivers
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_EZUSB is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# 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_QCAUX 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_SAMBA 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_VIVOPAY_SERIAL is not set
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_SSU100 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_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_YUREX is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
CONFIG_USB_ULPI=y
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_GPIO_PLATFORM=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_DAC124S085 is not set
CONFIG_LEDS_PWM=y
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_GPIO=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_NFC_DEVICES is not set
# CONFIG_ACCESSIBILITY 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

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_DRV_PCF8563=y
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 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 is not set
# 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_MSM6242 is not set
CONFIG_RTC_MXC=y
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_MX3_IPU is not set
# CONFIG_TIMB_DMA is not set
CONFIG_IMX_SDMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# 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_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_XATTR=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
# CONFIG_LOGFS 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_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_FRAME_POINTER=y
# CONFIG_LKDTM is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_DEBUG_USER=y
CONFIG_OC_ETM=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
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_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# 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=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# 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 is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# 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=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 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

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_RATIONAL=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
# CONFIG_AVERAGE is not set

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

* Re: Threaded Irqs (was "Changing Kernel thread priorities")
  2011-06-07 21:28       ` Threaded Irqs (was "Changing Kernel thread priorities") Tim Sander
@ 2011-06-07 21:56         ` Thomas Gleixner
  0 siblings, 0 replies; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-07 21:56 UTC (permalink / raw)
  To: Tim Sander; +Cc: linux-rt-users, linux-kernel

On Tue, 7 Jun 2011, Tim Sander wrote:
> Nevertheless are there still scheduling latencies for the usermode
> handler thread which then runs at rt prio 99 for about 1ms. I know
> this is not an preempt-rt kernel but i hoped to get better values out
> of this configuration. 
> 
> So if anybody has an idea how to get better latencies out of a 2.6.39
> kernel, please let me know.

The mainline forced irq thread handling is no guarantee for lower
latencies. We need to disable preemption via local_bh_disable() for
the forced threaded interrupts to satisfy the handler vs. softirq
assumptions. So you might get long lasting preempt disabled regions
due to long running interrupt handlers. Aside of that you still can
get long periods due to code which runs with preemption or interrupts
disabled. The forced threaded option has no way to change that.

It would be interesting to find the root cause for those >1ms
latencies. Tracing is your friend.

Thanks,

	tglx

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

* Re: Changing Kernel thread priorities
  2011-06-10 15:37                 ` Thomas Gleixner
@ 2011-06-11 17:16                   ` Remy Bohmer
  0 siblings, 0 replies; 33+ messages in thread
From: Remy Bohmer @ 2011-06-11 17:16 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Nicholas Mc Guire, Peter Zijlstra, Armin Steinhoff,
	Johannes Bauer, Monica Puig-Pey, Rolando Martins, linux-rt-users,
	linux-kernel

Hi,

> No, it's not. The root cause was a problem with the network softirq
> and a network driver, the softirq ->49 was a temporary workaround
> until we had enough information to find the real root cause. I wish
> I'd never committed that change at all.

Clear. Did not know it was already solved. I thought it was still an
issue. This changes things :-)

>> Race conditions that occur when a softirq preempts a related hardirq
>> what the driver did not expect or was designed for.
>
> And making it the other way round hides the problem, which is even
> worse. We want stuff to explode right away.

100% Agreed

> You can run into the same
> problem when the softirq holds a lock and the high prio irq thread
> boosts it.

OK.

Thanks for the explanation. I see no reason any more why setting the
prios default to 1 would be a bad thing.
The rest of the configuration in that case can then indeed done be
done by udev and other userland friends.

Kind regards,

Remy

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

* Re: Changing Kernel thread priorities
  2011-06-10 14:04               ` Remy Bohmer
@ 2011-06-10 15:37                 ` Thomas Gleixner
  2011-06-11 17:16                   ` Remy Bohmer
  0 siblings, 1 reply; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-10 15:37 UTC (permalink / raw)
  To: Remy Bohmer
  Cc: Nicholas Mc Guire, Peter Zijlstra, Armin Steinhoff,
	Johannes Bauer, Monica Puig-Pey, Rolando Martins, linux-rt-users,
	linux-kernel

On Fri, 10 Jun 2011, Remy Bohmer wrote:
> 2011/6/8 Thomas Gleixner <tglx@linutronix.de>:
> > On Wed, 8 Jun 2011, Remy Bohmer wrote:
> >> In real life you may want, for EXAMPLE, this setup:
> >> * prio 70: high priority motor control loop
> >> * prio 60: network device irq
> >> * prio 59: network softirqs
> >> * prio 55: some realtime task depending on networkingstack
> >> * prio 54: mass storage irq
> >> * prio 53: block device softirq
> >> * prio 52: some realtime task depending on mass-storage
> >> * prio 50: all remaining irq threads
> >> * prio 49: all remaining softirqs
> >>
> >> Assume here you do a ifconfig down and ifconfig up, in the current
> >> kernel behaviour you will see that the irq thread switches from prio
> >> 60 to 50.
> >> The irq-thread will become of a lower priority compared to its related
> >> softirqs due to this reason, which can result in a complete die of
> >> this network interface... even before it ever came back up again...
> >
> > Not really. If that's the case it needs to be investigated and
> > fixed.
> 
> I, of course, agree with that, but these cases are usually extremely
> hard to find, and occur typically only in the once-a-month-condition
> that you cannot reproduce...
> Do you remember why the priority of the softirqs was moved down from
> 50 to 49 ? IIRC this was because of the very same reason and IIRC
> still valid

No, it's not. The root cause was a problem with the network softirq
and a network driver, the softirq ->49 was a temporary workaround
until we had enough information to find the real root cause. I wish
I'd never committed that change at all.

> We do not have control over all kernel code, and new drivers are
> continuously being developed that make wrong implicit assumptions
> about the order of irq->sirq->everything else. Of course this is
> wrong, and there is no excuse, but it is a fact of life...
> In practice the softirq prio can be set to a higher value than 50 (or
> 1), and a hirq thread that is started at 50 (or 2) will result in
> situations that are not expected.
> 
> >> As mentioned before by Thomas, the configuration is a policy issue and
> >> must be set from user-context. I understand what he means by that and
> >> I agree, but there still has to be a mechanism to make the kernel
> >> remember the configuration set by the user to prevent all kinds of
> >> race conditions. You cannot demand from the user to run after
> >
> > Which race conditions?
> 
> Race conditions that occur when a softirq preempts a related hardirq
> what the driver did not expect or was designed for.

And making it the other way round hides the problem, which is even
worse. We want stuff to explode right away. You can run into the same
problem when the softirq holds a lock and the high prio irq thread
boosts it.

> > So moving the base priority down to 1 or 2 is probably the most
> > sensible solution to avoid that a newly brought up interrupt thread
> > interferes with anything in the rt domain and it's not rocket science
> > to adjust the priority in a ifup.post or with an udev rule.
> 
> At prio 1 or 2, _every_ RT-thread in the system is to be assumed to be
> more low-latency bound compared to _any_ interrupt handler. And you
> assume here that no user RT-thread in the system shall use any
> functionality of any driver that has an interrupt handler (otherwise
> you get the priority inversions issue)

Sigh. People who use RT threads should better know what they do and
configure their damned system correct. We cannot provide a solution
which takes every incarnatation of lusers into account.

> As mentioned in this thread before by someone else, you will get this
> old issue back: 'My drivers start to behave weird when I create a
> RT-thread...'

And I do not care at all. The answer is: Do not use an RT-thread when
you are not knowing what you are doing.

> The prio inversion issue between hirq/sirq will even become more
> worse, since there will be a smaller chance that softirqs will stay at
> prio 1 and thus there is less guarantee that they will stay below the
> hirq-prio all the time.

There is no such thing and if it's there, then it needs to be found
and fixed.

> Furthermore, I prefer the principle: _Nothing_ goes above interrupt
> (thread) priority unless there is a very special reason for it and it
> has been investigated that it is safe to do so. And a user-thread that
> requires functionality of a certain driver shall be set below the
> priority of the hirq-thread of that driver. The prio of the softirq
> must _always_ be between that user-thread and hirq-thread if there is
> a relation between the driver and softirq.
> 
> In that light I think prio 1/2 is more worse compared to 49/50. I
> think the current _default_ is okay, it makes the system at least
> boot.

It boots with 50 or whatever you set it to as well.

Thanks,

	tglx

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

* Re: Changing Kernel thread priorities
  2011-06-08 19:49             ` Thomas Gleixner
@ 2011-06-10 14:04               ` Remy Bohmer
  2011-06-10 15:37                 ` Thomas Gleixner
  0 siblings, 1 reply; 33+ messages in thread
From: Remy Bohmer @ 2011-06-10 14:04 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Nicholas Mc Guire, Peter Zijlstra, Armin Steinhoff,
	Johannes Bauer, Monica Puig-Pey, Rolando Martins, linux-rt-users,
	linux-kernel

Hi Thomas,

2011/6/8 Thomas Gleixner <tglx@linutronix.de>:
> On Wed, 8 Jun 2011, Remy Bohmer wrote:
>> In real life you may want, for EXAMPLE, this setup:
>> * prio 70: high priority motor control loop
>> * prio 60: network device irq
>> * prio 59: network softirqs
>> * prio 55: some realtime task depending on networkingstack
>> * prio 54: mass storage irq
>> * prio 53: block device softirq
>> * prio 52: some realtime task depending on mass-storage
>> * prio 50: all remaining irq threads
>> * prio 49: all remaining softirqs
>>
>> Assume here you do a ifconfig down and ifconfig up, in the current
>> kernel behaviour you will see that the irq thread switches from prio
>> 60 to 50.
>> The irq-thread will become of a lower priority compared to its related
>> softirqs due to this reason, which can result in a complete die of
>> this network interface... even before it ever came back up again...
>
> Not really. If that's the case it needs to be investigated and
> fixed.

I, of course, agree with that, but these cases are usually extremely
hard to find, and occur typically only in the once-a-month-condition
that you cannot reproduce...
Do you remember why the priority of the softirqs was moved down from
50 to 49 ? IIRC this was because of the very same reason and IIRC
still valid

We do not have control over all kernel code, and new drivers are
continuously being developed that make wrong implicit assumptions
about the order of irq->sirq->everything else. Of course this is
wrong, and there is no excuse, but it is a fact of life...
In practice the softirq prio can be set to a higher value than 50 (or
1), and a hirq thread that is started at 50 (or 2) will result in
situations that are not expected.

>> As mentioned before by Thomas, the configuration is a policy issue and
>> must be set from user-context. I understand what he means by that and
>> I agree, but there still has to be a mechanism to make the kernel
>> remember the configuration set by the user to prevent all kinds of
>> race conditions. You cannot demand from the user to run after
>
> Which race conditions?

Race conditions that occur when a softirq preempts a related hardirq
what the driver did not expect or was designed for.

>> executing a shell command like ifconfig or modprobe to run some sort
>> of init-script that repairs what the kernel assumed wrong. The wrong
>> assumptions the kernel does results in: deadlocks, priority inversion
>> issues between irq-threads and softirqs and realtime behaviour impact.
>
> If you do an ifdown/up then your prio 55 task is totally irrelevant
> until the interface is back to full operation again, which includes
> setting the priority right.

I already expected that remark after I pressed the send button of that
mail... This was just meant as an example, in which you can probably
shoot more holes in. It is not about the example, it is about the
essence of what I am trying to explain here.

> There is another gotcha with your approach. It only ever works when
> the interrupt descriptors are static and not dynamically
> allocated/freed. If they are fully dynamic then you have no
> possibility to store the prio information after a full teardown of a
> device.

It depends how it is being implemented.
A mechanism to specify the policy does not mean everything has to be
already in place the policy is about at the moment you specify the
policy.
In other words, a policy may describe situations that are going to
happen in the future, not necessarily situations that are actual now.

For example, something like this:
* A user specifies a table with policy information about what each
interrupt handler in the system should do when they are being created.
* When the interrupt handler is being installed, it is looked up in
the table at what priority and scheduling policy it needs to run. If
not specified, go for a default.
* Additionally: When the table is being updated, the already running
threads can being adjusted to the new policy.

> So moving the base priority down to 1 or 2 is probably the most
> sensible solution to avoid that a newly brought up interrupt thread
> interferes with anything in the rt domain and it's not rocket science
> to adjust the priority in a ifup.post or with an udev rule.

At prio 1 or 2, _every_ RT-thread in the system is to be assumed to be
more low-latency bound compared to _any_ interrupt handler. And you
assume here that no user RT-thread in the system shall use any
functionality of any driver that has an interrupt handler (otherwise
you get the priority inversions issue)
As mentioned in this thread before by someone else, you will get this
old issue back: 'My drivers start to behave weird when I create a
RT-thread...'
The prio inversion issue between hirq/sirq will even become more
worse, since there will be a smaller chance that softirqs will stay at
prio 1 and thus there is less guarantee that they will stay below the
hirq-prio all the time.

Furthermore, I prefer the principle: _Nothing_ goes above interrupt
(thread) priority unless there is a very special reason for it and it
has been investigated that it is safe to do so. And a user-thread that
requires functionality of a certain driver shall be set below the
priority of the hirq-thread of that driver. The prio of the softirq
must _always_ be between that user-thread and hirq-thread if there is
a relation between the driver and softirq.

In that light I think prio 1/2 is more worse compared to 49/50. I
think the current _default_ is okay, it makes the system at least
boot.

Kind regards,

Remy

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

* Re: Changing Kernel thread priorities
  2011-06-07 18:55                     ` Mark Hounschell
@ 2011-06-10 10:12                       ` Monica Puig-Pey
  0 siblings, 0 replies; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-10 10:12 UTC (permalink / raw)
  To: markh; +Cc: dmarkh, linux-rt-users, linux-kernel

El 07/06/11 20:55, Mark Hounschell escribió:
> On 06/07/2011 02:34 PM, Monica Puig-Pey wrote:
>> El 07/06/11 11:46, Mark Hounschell escribió:
>>> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>>>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>>>> Hi,
>>>>>>>> I use the following:
>>>>>>>>
>>>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>>>> print $1; }' | xargs echo)
>>>>>>>> for i in $PIDs
>>>>>>>> do
>>>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>>>> done
>>>>>>>>
>>>>>>>> This will change the kernel thread associated with an irq
>>>>>>>> handler to
>>>>>>>> RT FIFO prio 99.
>>>>>>>> Just change the script to your specific interrupt.
>>>>>>>>
>>>>>>>> Hope it helps,
>>>>>>>> Rolando
>>>>>>>>
>>>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>>>> wrote:
>>>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>>>> it.
>>>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>>>> specify the
>>>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>>>> I'm using:
>>>>>>>>>
>>>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param
>>>>>>>>> *);
>>>>>>>>>
>>>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>>>> init_module,
>>>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>>>
>>>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>>>
>>>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>>>
>>>>>>>>> Thanks you very much
>>>>>>>>>
>>>>>>>>> Mónica
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>> linux-rt-users" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>
>>>>>>> I need to change the priority from inside the driver, when creating
>>>>>>> the
>>>>>>> kernel thread.
>>>>>>> Your script is useful but it is done in user context,
>>>>>>> Any other help please?
>>>>>>
>>>>>> What I do is record the PID of the thread in the driver, then
>>>>>> create an
>>>>>> IOCTL for your driver that user land can call that either returns the
>>>>>> PID so you can do it in user land, or cause the IOCTL code to do
>>>>>> it in
>>>>>> the driver.
>>>>>>
>>>>>> The same can be done with the affinity of the IRQ if you record the
>>>>>> IRQ
>>>>>> number.
>>>>>>
>>>>>> Mark
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-rt-users" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>> But I don't have de PID of my Kthread, I only have the task_struc *
>>>>> that
>>>>> gives me the function:
>>>>>
>>>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>>>> void *data,
>>>>> const char namefmt[], ...)
>>>>>
>>>>> How could I get the PID, and which function should I use in the IOCTL
>>>>> (kernel context) for changing its priority?
>>>>>
>>>>
>>>> The PID can be obtained from within the interrupt handler its self via
>>>> current->pid.
>>>> Obviously an interrupt has to occur first but after one interrupt you
>>>> have it.
>>>>
>>>> Actually I had forgot how I handled this. Where I change the RT
>>>> priority
>>>> and cpu affinity is in what used to be called the Bottom Half and the
>>>> IOCTL
>>>> referred to above simply tells the BH to do it and with what values.
>>>>
>>>
>>> In interrupt handler code snippet:
>>>
>>> struct task_struct *TSK;
>>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>>>
>>> TSK = current;
>>>
>>> Code snippet from BH:
>>>
>>> if (((rtom_rtprio != 0) &&
>>> (rtom_rtprio != PARAM.sched_priority)) ||
>>> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>>>
>>> PARAM.sched_priority = rtom_rtprio;
>>> my_rtom_rtprio[COUNT] = rtom_rtprio;
>>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>>>
>>> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
>>> rtom_devices[BOARD].irq_task_pid = TSK->pid;
>>> }
>>>
>>> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
>>> interrupt must occur for this to happen and my BOARD never shares IRQs.
>>>
>>> Mark
>>>
>>
>> Thanks, your idea seems to be very useful to me. I was doing it very
>> similar, but I didn't use the "current" variable to know the
>> task_struct *.
>>
>> I have tried your suggestion on an easy example, but it didn't work.
>> Insmod returns through the kernel
>>
>> [11334.895499] kthread: Unknown symbol sched_setscheduler
>>
>> Code shown below:
>>
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/ioport.h>
>>
>> #include <linux/wait.h>
>> #include <linux/kthread.h>
>> #include <asm/io.h>
>> #include <linux/sched.h>
>>
>>
>> struct task_struct *ts;
>>
>> int thread(void *data)
>> {
>> struct task_struct *TSK;
>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>> TSK = current;
>>
>> PARAM.sched_priority = 50;
>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??
>>
>> while(1){
>> printk("Hi I am kernel thread!\n");
>> msleep(100);
>> if (kthread_should_stop())
>> break;
>> }
>> return 0;
>> }
>>
>>
>> int init_module(void)
>> {
>> printk(KERN_INFO "init_module() called\n");
>> ts=kthread_run(thread,NULL,"kthread");
>> return 0;
>> }
>>
>> void cleanup_module(void)
>> {
>> printk(KERN_INFO "cleanup_module() called\n");
>> kthread_stop(ts);
>> }
>> .
>>
>
> In kernel/sched.c
>
> EXPORT_SYMBOL_GPL(sched_setscheduler);
>
> If your driver is not GPL, you can't use it.
>
> Mark

I did it, it worked!!! thank you so much!!!!! :)
-- 
__________________________________________________________________________________

Mónica Puig-Pey González       E-mail: puigpeym@unican.es

Grupo de Computadores y Tiempo Real, Departamento de Electrónica y 
Computadores.
Facultad de Ciencias - Universidad de Cantabria
Av. de los Castros s/n. 39005 - Santander, España
__________________________________________________________________________________

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

* Re: Changing Kernel thread priorities
  2011-06-08 17:50           ` Remy Bohmer
  2011-06-08 19:49             ` Thomas Gleixner
@ 2011-06-09 11:19             ` Nicholas Mc Guire
  1 sibling, 0 replies; 33+ messages in thread
From: Nicholas Mc Guire @ 2011-06-09 11:19 UTC (permalink / raw)
  To: Remy Bohmer
  Cc: Peter Zijlstra, Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

On Wed, 08 Jun 2011, Remy Bohmer wrote:

> Hi,
> 
> >> So, in that case and in many other hotplug cases, you ruin the RT
> >> behaviour of the system just by the
> >> default-50-is-probably-right-assumption of the kernel.
> >> For systems where you have everything under control as a user/system
> >> designer, hotplug can also be under control as well.
> >>
> >
> > I dont't quite see that - the 50 default is well dokumented so you can
> > plan it into the rt design at system level. It simply means that you
> > would need to put your hard-rt tasks in the range of 50<prio<99.
> 
> This is another assumption as well. You assume here that any task
> bound to certain latencies must be above _all_ interrupt handlers, and
> tasks not bound to certain latencies must be set below _all_ interrupt
> handlers.
> In fact, in real life,  the prioritisation will be much more fine
> grained during runtime. One can have a RT task that depends on the
> networking stack, but not on mass-storage. In that case you want to
> move them out of the range of 50.

No implications are made on the "correct" priority - but as there is no
correct priority setting a well defined default and leaving it to the
user is the most resonable solution. The main issue with not changing it
from the current value is simply that it may change behavior of existing
systems that update and that is, if it provides no obvious benifit, not
a good thing to happen.

> The whole idea about threaded interrupts is, is that you can give them
> priorities such that they suit your specific application. It is
> therefore common practice that priorities does not stay at 49/50.
> 
> In real life you may want, for EXAMPLE, this setup:
> * prio 70: high priority motor control loop
> * prio 60: network device irq
> * prio 59: network softirqs
> * prio 55: some realtime task depending on networkingstack
> * prio 54: mass storage irq
> * prio 53: block device softirq
> * prio 52: some realtime task depending on mass-storage
> * prio 50: all remaining irq threads
> * prio 49: all remaining softirqs
> 
> Assume here you do a ifconfig down and ifconfig up, in the current
> kernel behaviour you will see that the irq thread switches from prio
> 60 to 50.
> The irq-thread will become of a lower priority compared to its related
> softirqs due to this reason, which can result in a complete die of
> this network interface... even before it ever came back up again...
> 
> As mentioned before by Thomas, the configuration is a policy issue and
> must be set from user-context. I understand what he means by that and
> I agree, but there still has to be a mechanism to make the kernel
> remember the configuration set by the user to prevent all kinds of
> race conditions. You cannot demand from the user to run after
> executing a shell command like ifconfig or modprobe to run some sort
> of init-script that repairs what the kernel assumed wrong. The wrong
> assumptions the kernel does results in: deadlocks, priority inversion
> issues between irq-threads and softirqs and realtime behaviour impact.

but you equally can not assume that a device comming back on-line always
should have the same priority. i.e. DAQ-card is opened by process A prioX
and then closed to be reopened by procsee B prio Y - the priority of the
DAQ-card IRQ  thread is not related and persistence here is dependant on 
the particular circumstances.

> Even UDEV cannot_fix_this_problem_ since it runs _after_ the kernel
> has set the wrong priorities of the irq threads and the problem it
> imposes already may have occurred.
> 
> Setting the priorities right once is already complicated enough, it
> makes it far more complex if all kinds of race conditions and
> limitations need to be taken into account due to this mentioned
> auto-reset-to-50(-or-1)-assumptions of the kernel...
> True, there must be a safe default for booting, and 49/50 is good
> enough for that.
> 
> So, you might disagree the way our patches to solve this problem are
> implemented, I can buy that, it is just at the level of 'works-for-me'
> . Since this discussion frequently appears back on the mailinglist
> makes clear that this _is_ an issue that is relevant. Instead of
> ignoring or denying this issue, we should figure out what is the
> _best_way_ to solve it.
> I hope to see great and constructive suggestions soon on this list, I
> am very willing to implement it :-)
>

so maybe a comlet set of requirements is needed first rather than ad-hoc
solutions for special cases - Im quite sure the non-persistant case is only
one of a few issues one can find here.

hofrat

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

* Re: Changing Kernel thread priorities
  2011-06-08 17:50           ` Remy Bohmer
@ 2011-06-08 19:49             ` Thomas Gleixner
  2011-06-10 14:04               ` Remy Bohmer
  2011-06-09 11:19             ` Nicholas Mc Guire
  1 sibling, 1 reply; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-08 19:49 UTC (permalink / raw)
  To: Remy Bohmer
  Cc: Nicholas Mc Guire, Peter Zijlstra, Armin Steinhoff,
	Johannes Bauer, Monica Puig-Pey, Rolando Martins, linux-rt-users,
	linux-kernel

On Wed, 8 Jun 2011, Remy Bohmer wrote:
> In real life you may want, for EXAMPLE, this setup:
> * prio 70: high priority motor control loop
> * prio 60: network device irq
> * prio 59: network softirqs
> * prio 55: some realtime task depending on networkingstack
> * prio 54: mass storage irq
> * prio 53: block device softirq
> * prio 52: some realtime task depending on mass-storage
> * prio 50: all remaining irq threads
> * prio 49: all remaining softirqs
> 
> Assume here you do a ifconfig down and ifconfig up, in the current
> kernel behaviour you will see that the irq thread switches from prio
> 60 to 50.
> The irq-thread will become of a lower priority compared to its related
> softirqs due to this reason, which can result in a complete die of
> this network interface... even before it ever came back up again...

Not really. If that's the case it needs to be investigated and
fixed.

> As mentioned before by Thomas, the configuration is a policy issue and
> must be set from user-context. I understand what he means by that and
> I agree, but there still has to be a mechanism to make the kernel
> remember the configuration set by the user to prevent all kinds of
> race conditions. You cannot demand from the user to run after

Which race conditions?

> executing a shell command like ifconfig or modprobe to run some sort
> of init-script that repairs what the kernel assumed wrong. The wrong
> assumptions the kernel does results in: deadlocks, priority inversion
> issues between irq-threads and softirqs and realtime behaviour impact.

If you do an ifdown/up then your prio 55 task is totally irrelevant
until the interface is back to full operation again, which includes
setting the priority right.

There is another gotcha with your approach. It only ever works when
the interrupt descriptors are static and not dynamically
allocated/freed. If they are fully dynamic then you have no
possibility to store the prio information after a full teardown of a
device.

So moving the base priority down to 1 or 2 is probably the most
sensible solution to avoid that a newly brought up interrupt thread
interferes with anything in the rt domain and it's not rocket science
to adjust the priority in a ifup.post or with an udev rule.

Thanks,

	tglx

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

* Re: Changing Kernel thread priorities
  2011-06-07 23:35         ` Nicholas Mc Guire
@ 2011-06-08 17:50           ` Remy Bohmer
  2011-06-08 19:49             ` Thomas Gleixner
  2011-06-09 11:19             ` Nicholas Mc Guire
  0 siblings, 2 replies; 33+ messages in thread
From: Remy Bohmer @ 2011-06-08 17:50 UTC (permalink / raw)
  To: Nicholas Mc Guire
  Cc: Peter Zijlstra, Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

Hi,

>> So, in that case and in many other hotplug cases, you ruin the RT
>> behaviour of the system just by the
>> default-50-is-probably-right-assumption of the kernel.
>> For systems where you have everything under control as a user/system
>> designer, hotplug can also be under control as well.
>>
>
> I dont't quite see that - the 50 default is well dokumented so you can
> plan it into the rt design at system level. It simply means that you
> would need to put your hard-rt tasks in the range of 50<prio<99.

This is another assumption as well. You assume here that any task
bound to certain latencies must be above _all_ interrupt handlers, and
tasks not bound to certain latencies must be set below _all_ interrupt
handlers.
In fact, in real life,  the prioritisation will be much more fine
grained during runtime. One can have a RT task that depends on the
networking stack, but not on mass-storage. In that case you want to
move them out of the range of 50.
The whole idea about threaded interrupts is, is that you can give them
priorities such that they suit your specific application. It is
therefore common practice that priorities does not stay at 49/50.

In real life you may want, for EXAMPLE, this setup:
* prio 70: high priority motor control loop
* prio 60: network device irq
* prio 59: network softirqs
* prio 55: some realtime task depending on networkingstack
* prio 54: mass storage irq
* prio 53: block device softirq
* prio 52: some realtime task depending on mass-storage
* prio 50: all remaining irq threads
* prio 49: all remaining softirqs

Assume here you do a ifconfig down and ifconfig up, in the current
kernel behaviour you will see that the irq thread switches from prio
60 to 50.
The irq-thread will become of a lower priority compared to its related
softirqs due to this reason, which can result in a complete die of
this network interface... even before it ever came back up again...

As mentioned before by Thomas, the configuration is a policy issue and
must be set from user-context. I understand what he means by that and
I agree, but there still has to be a mechanism to make the kernel
remember the configuration set by the user to prevent all kinds of
race conditions. You cannot demand from the user to run after
executing a shell command like ifconfig or modprobe to run some sort
of init-script that repairs what the kernel assumed wrong. The wrong
assumptions the kernel does results in: deadlocks, priority inversion
issues between irq-threads and softirqs and realtime behaviour impact.
Even UDEV cannot_fix_this_problem_ since it runs _after_ the kernel
has set the wrong priorities of the irq threads and the problem it
imposes already may have occurred.

Setting the priorities right once is already complicated enough, it
makes it far more complex if all kinds of race conditions and
limitations need to be taken into account due to this mentioned
auto-reset-to-50(-or-1)-assumptions of the kernel...
True, there must be a safe default for booting, and 49/50 is good
enough for that.

So, you might disagree the way our patches to solve this problem are
implemented, I can buy that, it is just at the level of 'works-for-me'
. Since this discussion frequently appears back on the mailinglist
makes clear that this _is_ an issue that is relevant. Instead of
ignoring or denying this issue, we should figure out what is the
_best_way_ to solve it.
I hope to see great and constructive suggestions soon on this list, I
am very willing to implement it :-)

Kind regards,

Remy

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

* Re: Changing Kernel thread priorities
  2011-06-07 15:15           ` Thomas Gleixner
@ 2011-06-07 23:38             ` Nicholas Mc Guire
  0 siblings, 0 replies; 33+ messages in thread
From: Nicholas Mc Guire @ 2011-06-07 23:38 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Peter Zijlstra, Remy Bohmer, Armin Steinhoff, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

On Tue, 07 Jun 2011, Thomas Gleixner wrote:

> On Tue, 7 Jun 2011, Peter Zijlstra wrote:
> > On Tue, 2011-06-07 at 13:02 +0200, Remy Bohmer wrote:
> > > Well, I 100% agree that it must be under full userspace control to be
> > > able to set the priorities. But, the kernel default assumption of
> > > starting everything at 50 is wrong as well.
> > > Imagine the following situation:
> > > * Realtime application is running and has threads active in the range
> > > of prios 20 - 90.
> > > * Now bring up a network device, it immediately starts spamming the
> > > system at prio 50 _before_ you have the chance to set it below 20 by
> > > means of chrt.
> > > * RT behaviour is gone!
> > 
> > Good point I guess, Thomas should we default to 1 for everything?
> 
> No objections.

I think that splitting the range makes more sense - you are now potentially
reverting the argument brought up before.

"My drivers behave properly until I load any RT-task"

hofrat

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

* Re: Changing Kernel thread priorities
  2011-06-07 11:02       ` Remy Bohmer
  2011-06-07 14:14         ` Peter Zijlstra
@ 2011-06-07 23:35         ` Nicholas Mc Guire
  2011-06-08 17:50           ` Remy Bohmer
  1 sibling, 1 reply; 33+ messages in thread
From: Nicholas Mc Guire @ 2011-06-07 23:35 UTC (permalink / raw)
  To: Remy Bohmer
  Cc: Peter Zijlstra, Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

On Tue, 07 Jun 2011, Remy Bohmer wrote:

> Hi All,
> 
> 2011/6/7 Peter Zijlstra <peterz@infradead.org>:
> > On Tue, 2011-06-07 at 11:40 +0200, Armin Steinhoff wrote:
> >> Hi,
> >>
> >> when I read all these confusing statements here ( in german it looks
> >> like an "Eiertanz") ?... I can only say:
> >>
> >> - do the basic stuff in a minimal kernel driver
> >> - use UIO (or VFIO for PCI devices)
> >
> > I see no requirement for any of those horrid things to be used. You can
> > write a full on proper kernel driver, it just cannot set kernel thread
> > priorities to a sane value (let them all default to 50 or so).
> >
> > Then have a user space script or whatever set the kthread priorities.
> >> and you get clean control about your real-time priorities.
> >> I think changing the priorities of "interrupt threads" inside the kernel
> >> could lead to strange race conditions in the kernel.
> 
> Well, I 100% agree that it must be under full userspace control to be
> able to set the priorities. But, the kernel default assumption of
> starting everything at 50 is wrong as well.
> Imagine the following situation:
> * Realtime application is running and has threads active in the range
> of prios 20 - 90.
> * Now bring up a network device, it immediately starts spamming the
> system at prio 50 _before_ you have the chance to set it below 20 by
> means of chrt.
> * RT behaviour is gone!
> 
> So, in that case and in many other hotplug cases, you ruin the RT
> behaviour of the system just by the
> default-50-is-probably-right-assumption of the kernel.
> For systems where you have everything under control as a user/system
> designer, hotplug can also be under control as well.
>

I dont't quite see that - the 50 default is well dokumented so you can
plan it into the rt design at system level. It simply means that you
would need to put your hard-rt tasks in the range of 50<prio<99. 

The actual value is quite irrelevant aslong as it is well defined, and 
leaves a range free above suitably large for a rt task set (if you need
more than 5 distinct priorities for a rt task-set it generally means you
are using implicid locking any way)

I dont see the utility of adding a further interface that provides the same
level of configuration that the current user space tools do, and having one
interface for interrupt threads and one for tasks does not really simplify
things - from a rt-task-set perspective the differentiation betwen rt-tasks
and rt-related interrupt threads does not really make sens so keeping the
management in one interface seems more resonable to me.

hofrat 

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

* Re: Changing Kernel thread priorities
  2011-06-07 18:34                   ` Monica Puig-Pey
@ 2011-06-07 18:55                     ` Mark Hounschell
  2011-06-10 10:12                       ` Monica Puig-Pey
  0 siblings, 1 reply; 33+ messages in thread
From: Mark Hounschell @ 2011-06-07 18:55 UTC (permalink / raw)
  To: Monica Puig-Pey; +Cc: dmarkh, Rolando Martins, linux-rt-users, linux-kernel

On 06/07/2011 02:34 PM, Monica Puig-Pey wrote:
> El 07/06/11 11:46, Mark Hounschell escribió:
>> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>>> Hi,
>>>>>>> I use the following:
>>>>>>>
>>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>>> print $1; }' | xargs echo)
>>>>>>> for i in $PIDs
>>>>>>> do
>>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>>> done
>>>>>>>
>>>>>>> This will change the kernel thread associated with an irq handler to
>>>>>>> RT FIFO prio 99.
>>>>>>> Just change the script to your specific interrupt.
>>>>>>>
>>>>>>> Hope it helps,
>>>>>>> Rolando
>>>>>>>
>>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>>> wrote:
>>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>>> it.
>>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>>> specify the
>>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>>> I'm using:
>>>>>>>>
>>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param
>>>>>>>> *);
>>>>>>>>
>>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>>> init_module,
>>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>>
>>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>>
>>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>>
>>>>>>>> Thanks you very much
>>>>>>>>
>>>>>>>> Mónica
>>>>>>>>
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> linux-rt-users" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>
>>>>>> I need to change the priority from inside the driver, when creating
>>>>>> the
>>>>>> kernel thread.
>>>>>> Your script is useful but it is done in user context,
>>>>>> Any other help please?
>>>>>
>>>>> What I do is record the PID of the thread in the driver, then
>>>>> create an
>>>>> IOCTL for your driver that user land can call that either returns the
>>>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>>>> the driver.
>>>>>
>>>>> The same can be done with the affinity of the IRQ if you record the
>>>>> IRQ
>>>>> number.
>>>>>
>>>>> Mark
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-rt-users" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> But I don't have de PID of my Kthread, I only have the task_struc *
>>>> that
>>>> gives me the function:
>>>>
>>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>>> void *data,
>>>> const char namefmt[], ...)
>>>>
>>>> How could I get the PID, and which function should I use in the IOCTL
>>>> (kernel context) for changing its priority?
>>>>
>>>
>>> The PID can be obtained from within the interrupt handler its self via
>>> current->pid.
>>> Obviously an interrupt has to occur first but after one interrupt you
>>> have it.
>>>
>>> Actually I had forgot how I handled this. Where I change the RT priority
>>> and cpu affinity is in what used to be called the Bottom Half and the
>>> IOCTL
>>> referred to above simply tells the BH to do it and with what values.
>>>
>>
>> In interrupt handler code snippet:
>>
>> struct task_struct *TSK;
>> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>>
>> TSK = current;
>>
>> Code snippet from BH:
>>
>> if (((rtom_rtprio != 0) &&
>> (rtom_rtprio != PARAM.sched_priority)) ||
>> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>>
>> PARAM.sched_priority = rtom_rtprio;
>> my_rtom_rtprio[COUNT] = rtom_rtprio;
>> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>>
>> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
>> rtom_devices[BOARD].irq_task_pid = TSK->pid;
>> }
>>
>> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
>> interrupt must occur for this to happen and my BOARD never shares IRQs.
>>
>> Mark
>>
>
> Thanks, your idea seems to be very useful to me. I was doing it very
> similar, but I didn't use the "current" variable to know the task_struct *.
>
> I have tried your suggestion on an easy example, but it didn't work.
> Insmod returns through the kernel
>
> [11334.895499] kthread: Unknown symbol sched_setscheduler
>
> Code shown below:
>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/ioport.h>
>
> #include <linux/wait.h>
> #include <linux/kthread.h>
> #include <asm/io.h>
> #include <linux/sched.h>
>
>
> struct task_struct *ts;
>
> int thread(void *data)
> {
> struct task_struct *TSK;
> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
> TSK = current;
>
> PARAM.sched_priority = 50;
> sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??
>
> while(1){
> printk("Hi I am kernel thread!\n");
> msleep(100);
> if (kthread_should_stop())
> break;
> }
> return 0;
> }
>
>
> int init_module(void)
> {
> printk(KERN_INFO "init_module() called\n");
> ts=kthread_run(thread,NULL,"kthread");
> return 0;
> }
>
> void cleanup_module(void)
> {
> printk(KERN_INFO "cleanup_module() called\n");
> kthread_stop(ts);
> }
> .
>

In kernel/sched.c

EXPORT_SYMBOL_GPL(sched_setscheduler);

If your driver is not GPL, you can't use it.

Mark

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

* Re: Changing Kernel thread priorities
  2011-06-07  9:46                 ` Mark Hounschell
@ 2011-06-07 18:34                   ` Monica Puig-Pey
  2011-06-07 18:55                     ` Mark Hounschell
  0 siblings, 1 reply; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-07 18:34 UTC (permalink / raw)
  To: dmarkh; +Cc: markh, Rolando Martins, linux-rt-users, linux-kernel

El 07/06/11 11:46, Mark Hounschell escribió:
> On 06/07/2011 05:14 AM, Mark Hounschell wrote:
>> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>>> El 06/06/11 18:49, Mark Hounschell escribió:
>>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>>> Hi,
>>>>>> I use the following:
>>>>>>
>>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>>> print $1; }' | xargs echo)
>>>>>> for i in $PIDs
>>>>>> do
>>>>>> ret=$(chrt -f -p 99 $i)
>>>>>> done
>>>>>>
>>>>>> This will change the kernel thread associated with an irq handler to
>>>>>> RT FIFO prio 99.
>>>>>> Just change the script to your specific interrupt.
>>>>>>
>>>>>> Hope it helps,
>>>>>> Rolando
>>>>>>
>>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey
>>>>>> wrote:
>>>>>>> I am writing a driver which has one kernel thread associated with
>>>>>>> it.
>>>>>>> I want to change the priority of this thread, so that I can
>>>>>>> specify the
>>>>>>> order in which it is scheduled following an interrupt.
>>>>>>> I'm using:
>>>>>>>
>>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>>>
>>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>>> init_module,
>>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>>
>>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>>
>>>>>>> What do I call to change a kernel thread priority?
>>>>>>>
>>>>>>> Thanks you very much
>>>>>>>
>>>>>>> Mónica
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> linux-rt-users" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>
>>>>> I need to change the priority from inside the driver, when creating
>>>>> the
>>>>> kernel thread.
>>>>> Your script is useful but it is done in user context,
>>>>> Any other help please?
>>>>
>>>> What I do is record the PID of the thread in the driver, then create an
>>>> IOCTL for your driver that user land can call that either returns the
>>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>>> the driver.
>>>>
>>>> The same can be done with the affinity of the IRQ if you record the IRQ
>>>> number.
>>>>
>>>> Mark
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> But I don't have de PID of my Kthread, I only have the task_struc * that
>>> gives me the function:
>>>
>>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>>> void *data,
>>> const char namefmt[], ...)
>>>
>>> How could I get the PID, and which function should I use in the IOCTL
>>> (kernel context) for changing its priority?
>>>
>>
>> The PID can be obtained from within the interrupt handler its self via
>> current->pid.
>> Obviously an interrupt has to occur first but after one interrupt you
>> have it.
>>
>> Actually I had forgot how I handled this. Where I change the RT priority
>> and cpu affinity is in what used to be called the Bottom Half and the
>> IOCTL
>> referred to above simply tells the BH to do it and with what values.
>>
>
> In interrupt handler code snippet:
>
> struct task_struct *TSK;
> struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
>
> TSK = current;
>
> Code snippet from BH:
>
> if (((rtom_rtprio != 0) &&
> (rtom_rtprio != PARAM.sched_priority)) ||
> (my_rtom_rtprio[BOARD] != rtom_rtprio)) {
>
> PARAM.sched_priority = rtom_rtprio;
> my_rtom_rtprio[COUNT] = rtom_rtprio;
> sched_setscheduler(TSK, SCHED_FIFO, &PARAM);
>
> set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
> rtom_devices[BOARD].irq_task_pid = TSK->pid;
> }
>
> rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An
> interrupt must occur for this to happen and my BOARD never shares IRQs.
>
> Mark
>

Thanks, your idea seems to be very useful to me. I was doing it very 
similar, but I didn't use the "current" variable to know the task_struct *.

I have tried your suggestion on an easy example, but it didn't work.
Insmod returns through the kernel

	[11334.895499] kthread: Unknown symbol sched_setscheduler

Code shown below:

#include <linux/module.h>	
#include <linux/kernel.h>
#include <linux/ioport.h>

#include <linux/wait.h>
#include <linux/kthread.h>
#include <asm/io.h>
#include <linux/sched.h>


struct task_struct *ts;

int thread(void *data)
{
   struct task_struct *TSK;
   struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };
   TSK = current;

   PARAM.sched_priority = 50;
   sched_setscheduler(TSK, SCHED_FIFO, &PARAM); // <-- unknown symbol??

   while(1){
     printk("Hi I am kernel thread!\n");
     msleep(100);
     if (kthread_should_stop())
       break;		
}
         return 0;
}


int init_module(void)
{
   printk(KERN_INFO "init_module() called\n");
   ts=kthread_run(thread,NULL,"kthread");
          return 0;
}

void cleanup_module(void)
{
   printk(KERN_INFO "cleanup_module() called\n");
   kthread_stop(ts);
}

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

* Re: Changing Kernel thread priorities
  2011-06-07 14:14         ` Peter Zijlstra
  2011-06-07 14:57           ` Lucas De Marchi
@ 2011-06-07 15:15           ` Thomas Gleixner
  2011-06-07 23:38             ` Nicholas Mc Guire
  1 sibling, 1 reply; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-07 15:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Remy Bohmer, Armin Steinhoff, Johannes Bauer, Monica Puig-Pey,
	Rolando Martins, linux-rt-users, linux-kernel

On Tue, 7 Jun 2011, Peter Zijlstra wrote:
> On Tue, 2011-06-07 at 13:02 +0200, Remy Bohmer wrote:
> > Well, I 100% agree that it must be under full userspace control to be
> > able to set the priorities. But, the kernel default assumption of
> > starting everything at 50 is wrong as well.
> > Imagine the following situation:
> > * Realtime application is running and has threads active in the range
> > of prios 20 - 90.
> > * Now bring up a network device, it immediately starts spamming the
> > system at prio 50 _before_ you have the chance to set it below 20 by
> > means of chrt.
> > * RT behaviour is gone!
> 
> Good point I guess, Thomas should we default to 1 for everything?

No objections.

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

* Re: Changing Kernel thread priorities
  2011-06-07 14:14         ` Peter Zijlstra
@ 2011-06-07 14:57           ` Lucas De Marchi
  2011-06-07 15:15           ` Thomas Gleixner
  1 sibling, 0 replies; 33+ messages in thread
From: Lucas De Marchi @ 2011-06-07 14:57 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Remy Bohmer, Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

On Tue, Jun 7, 2011 at 11:14, Peter Zijlstra <peterz@infradead.org> wrote:
> > Well, I 100% agree that it must be under full userspace control to be
> > able to set the priorities. But, the kernel default assumption of
> > starting everything at 50 is wrong as well.
> > Imagine the following situation:
> > * Realtime application is running and has threads active in the range
> > of prios 20 - 90.
> > * Now bring up a network device, it immediately starts spamming the
> > system at prio 50 _before_ you have the chance to set it below 20 by
> > means of chrt.
> > * RT behaviour is gone!

Why is the application using priorities in the range 20-90 if it's
well known that we default RT kernel threads to 50?

IMO it's a mistake in the application.


Lucas De Marchi

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

* Re: Changing Kernel thread priorities
  2011-06-07 11:02       ` Remy Bohmer
@ 2011-06-07 14:14         ` Peter Zijlstra
  2011-06-07 14:57           ` Lucas De Marchi
  2011-06-07 15:15           ` Thomas Gleixner
  2011-06-07 23:35         ` Nicholas Mc Guire
  1 sibling, 2 replies; 33+ messages in thread
From: Peter Zijlstra @ 2011-06-07 14:14 UTC (permalink / raw)
  To: Remy Bohmer
  Cc: Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

On Tue, 2011-06-07 at 13:02 +0200, Remy Bohmer wrote:
> Hi All,
> 
> 2011/6/7 Peter Zijlstra <peterz@infradead.org>:
> > On Tue, 2011-06-07 at 11:40 +0200, Armin Steinhoff wrote:
> >> Hi,
> >>
> >> when I read all these confusing statements here ( in german it looks
> >> like an "Eiertanz")  ... I can only say:
> >>
> >> - do the basic stuff in a minimal kernel driver
> >> - use UIO (or VFIO for PCI devices)
> >
> > I see no requirement for any of those horrid things to be used. You can
> > write a full on proper kernel driver, it just cannot set kernel thread
> > priorities to a sane value (let them all default to 50 or so).
> >
> > Then have a user space script or whatever set the kthread priorities.
> >> and you get clean control about your real-time priorities.
> >> I think changing the priorities of "interrupt threads" inside the kernel
> >> could lead to strange race conditions in the kernel.
> 
> Well, I 100% agree that it must be under full userspace control to be
> able to set the priorities. But, the kernel default assumption of
> starting everything at 50 is wrong as well.
> Imagine the following situation:
> * Realtime application is running and has threads active in the range
> of prios 20 - 90.
> * Now bring up a network device, it immediately starts spamming the
> system at prio 50 _before_ you have the chance to set it below 20 by
> means of chrt.
> * RT behaviour is gone!

Good point I guess, Thomas should we default to 1 for everything?


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

* Re: Changing Kernel thread priorities
  2011-06-07  9:37     ` Peter Zijlstra
@ 2011-06-07 11:02       ` Remy Bohmer
  2011-06-07 14:14         ` Peter Zijlstra
  2011-06-07 23:35         ` Nicholas Mc Guire
  0 siblings, 2 replies; 33+ messages in thread
From: Remy Bohmer @ 2011-06-07 11:02 UTC (permalink / raw)
  To: Peter Zijlstra, Armin Steinhoff, Thomas Gleixner, Johannes Bauer,
	Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel

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

Hi All,

2011/6/7 Peter Zijlstra <peterz@infradead.org>:
> On Tue, 2011-06-07 at 11:40 +0200, Armin Steinhoff wrote:
>> Hi,
>>
>> when I read all these confusing statements here ( in german it looks
>> like an "Eiertanz")  ... I can only say:
>>
>> - do the basic stuff in a minimal kernel driver
>> - use UIO (or VFIO for PCI devices)
>
> I see no requirement for any of those horrid things to be used. You can
> write a full on proper kernel driver, it just cannot set kernel thread
> priorities to a sane value (let them all default to 50 or so).
>
> Then have a user space script or whatever set the kthread priorities.
>> and you get clean control about your real-time priorities.
>> I think changing the priorities of "interrupt threads" inside the kernel
>> could lead to strange race conditions in the kernel.

Well, I 100% agree that it must be under full userspace control to be
able to set the priorities. But, the kernel default assumption of
starting everything at 50 is wrong as well.
Imagine the following situation:
* Realtime application is running and has threads active in the range
of prios 20 - 90.
* Now bring up a network device, it immediately starts spamming the
system at prio 50 _before_ you have the chance to set it below 20 by
means of chrt.
* RT behaviour is gone!

So, in that case and in many other hotplug cases, you ruin the RT
behaviour of the system just by the
default-50-is-probably-right-assumption of the kernel.
For systems where you have everything under control as a user/system
designer, hotplug can also be under control as well.

To solve this we have the patchset in use as attached to this mail. It
is a newer version of the old set mentioned earlier in this mail
thread.
The opinion of Thomas about this subject is quite clear so I will not
post it as a cleaned up patchset, although I believe we reworked all
his previous major remarks about this set.

For everyone else who can do something useful with it: go ahead. It
should apply to 2.6.33.9-rt31
It creates entries in /proc/irq for you to setup the priorities after
booting. (/proc/irq/hirq-prio and /proc/irq/sirq-prio), but also per
driver in /proc/irq/<irq-id>/<name>/irqprio
In /proc/irq/[hs]irq-prio you can, for example, enter the following text:
* at91_udc:22,ohci_hcd:usb1:22,atmel_spi:22,33

This results in:
* starting the at91_udc at prio 22
* starting ohci:usb1 also at prio 22
* atmel_spi at 22
* overall default moved from 50 to 33

Kind regards,

Remy

[-- Attachment #2: irqprio-patches.tar.gz --]
[-- Type: application/x-gzip, Size: 5565 bytes --]

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

* Re: Changing Kernel thread priorities
  2011-06-07  9:14               ` Mark Hounschell
@ 2011-06-07  9:46                 ` Mark Hounschell
  2011-06-07 18:34                   ` Monica Puig-Pey
  0 siblings, 1 reply; 33+ messages in thread
From: Mark Hounschell @ 2011-06-07  9:46 UTC (permalink / raw)
  To: Monica Puig-Pey
  Cc: dmarkh, markh, Rolando Martins, linux-rt-users, linux-kernel

On 06/07/2011 05:14 AM, Mark Hounschell wrote:
> On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
>> El 06/06/11 18:49, Mark Hounschell escribió:
>>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>>> Hi,
>>>>> I use the following:
>>>>>
>>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>>> print $1; }' | xargs echo)
>>>>> for i in $PIDs
>>>>> do
>>>>> ret=$(chrt -f -p 99 $i)
>>>>> done
>>>>>
>>>>> This will change the kernel thread associated with an irq handler to
>>>>> RT FIFO prio 99.
>>>>> Just change the script to your specific interrupt.
>>>>>
>>>>> Hope it helps,
>>>>> Rolando
>>>>>
>>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>>>> wrote:
>>>>>> I am writing a driver which has one kernel thread associated with it.
>>>>>> I want to change the priority of this thread, so that I can specify the
>>>>>> order in which it is scheduled following an interrupt.
>>>>>> I'm using:
>>>>>>
>>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>>
>>>>>> but it doesn't work. I tried to change the priority from the
>>>>>> init_module,
>>>>>> and also from the Kernel Thread, but there is no way.
>>>>>>
>>>>>> Kernel version is 2.6.31-11-rt
>>>>>>
>>>>>> What do I call to change a kernel thread priority?
>>>>>>
>>>>>> Thanks you very much
>>>>>>
>>>>>> Mónica
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-rt-users" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>
>>>> I need to change the priority from inside the driver, when creating the
>>>> kernel thread.
>>>> Your script is useful but it is done in user context,
>>>> Any other help please?
>>>
>>> What I do is record the PID of the thread in the driver, then create an
>>> IOCTL for your driver that user land can call that either returns the
>>> PID so you can do it in user land, or cause the IOCTL code to do it in
>>> the driver.
>>>
>>> The same can be done with the affinity of the IRQ if you record the IRQ
>>> number.
>>>
>>> Mark
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-rt-users" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> But I don't have de PID of my Kthread, I only have the task_struc * that
>> gives me the function:
>>
>> struct task_struct *kthread_create(int (*threadfn)(void *data),
>> void *data,
>> const char namefmt[], ...)
>>
>> How could I get the PID, and which function should I use in the IOCTL
>> (kernel context) for changing its priority?
>>
>
> The PID can be obtained from within the interrupt handler its self via
> current->pid.
> Obviously an interrupt has to occur first but after one interrupt you have it.
>
> Actually I had forgot how I handled this. Where I change the RT priority
> and cpu affinity is in what used to be called the Bottom Half and the IOCTL
> referred to above simply tells the BH to do it and with what values.
>

In interrupt handler code snippet:

struct task_struct *TSK;
struct sched_param PARAM = {.sched_priority = MAX_RT_PRIO };

         TSK = current;

Code snippet from BH:

         if (((rtom_rtprio != 0) &&
              (rtom_rtprio != PARAM.sched_priority)) ||
              (my_rtom_rtprio[BOARD] != rtom_rtprio)) {

                 PARAM.sched_priority = rtom_rtprio;
                 my_rtom_rtprio[COUNT] = rtom_rtprio;
                 sched_setscheduler(TSK, SCHED_FIFO, &PARAM);

                 set_cpus_allowed(TSK, rtom_devices[BOARD].irq_cpu_mask);
                 rtom_devices[BOARD].irq_task_pid = TSK->pid;
        }

rtom_rtprio and irq_cpu_mask are set by userland via an IOCTL. An interrupt 
must occur for this to happen and my BOARD never shares IRQs.

Mark


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

* Re: Changing Kernel thread priorities
  2011-06-07  8:41 ` Thomas Gleixner
@ 2011-06-07  9:40   ` Armin Steinhoff
  2011-06-07  9:37     ` Peter Zijlstra
  0 siblings, 1 reply; 33+ messages in thread
From: Armin Steinhoff @ 2011-06-07  9:40 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Johannes Bauer, Peter Zijlstra, Monica Puig-Pey, Rolando Martins,
	linux-rt-users, linux-kernel


Hi,

when I read all these confusing statements here ( in german it looks 
like an "Eiertanz")  ... I can only say:

- do the basic stuff in a minimal kernel driver
- use UIO (or VFIO for PCI devices)

and you get clean control about your real-time priorities.

I think changing the priorities of "interrupt threads" inside the kernel 
could lead to strange race conditions in the kernel.
That seems to be the reason for that "Eiertanz" here :)

--Armin





Thomas Gleixner wrote:
> On Tue, 7 Jun 2011, Johannes Bauer wrote:
>
> Please stop top-posting and use proper line breaks at 78
>
>>> Peter Zijlstra wrote:
>>>> "Monica Puig-Pey" wrote:
>>>> I need to change the priority from inside the driver, when creating the
>>>> kernel thread.
>>> No you don't. How does you driver know about what priority is correct
>>> wrt all the other running RT tasks on the system?
>>>
>>> Determining the right priority in a fixed priority scheduling system is
>>> a system wide problem, nobody but the administrator can possibly even
>>> begin to solve it.
>>>
>>> There's a reason all RT irq threads are started at 50, its plain
>>> impossible to do better.
>> Absolutly correct!
>>
>> However, if you are running the system on an embedded platform,
>> where the _WHOLE_ system (including priorities) is preconfigured and
>> never touched, starting a irq thread with the right prio from start
>> is a more straightforward method than having to invoke a script that
>> changes it using userspace chrt tool.
> Feel free to do that for your embedded system and carry the patch for
> yourself if you think it's worth to avoid the extra init script.
>
> But we do _not_ add stuff like this to the mainline simply because
> there is no way to find a prio setting which is appropriate for all
> users of a particular driver.
>
> Aside of that the extra init script is definitely less annoying to
> maintain than the crap you need to hack into random drivers.
>
> Thanks,
>
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


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

* Re: Changing Kernel thread priorities
  2011-06-07  9:40   ` Armin Steinhoff
@ 2011-06-07  9:37     ` Peter Zijlstra
  2011-06-07 11:02       ` Remy Bohmer
  0 siblings, 1 reply; 33+ messages in thread
From: Peter Zijlstra @ 2011-06-07  9:37 UTC (permalink / raw)
  To: Armin Steinhoff
  Cc: Thomas Gleixner, Johannes Bauer, Monica Puig-Pey,
	Rolando Martins, linux-rt-users, linux-kernel

On Tue, 2011-06-07 at 11:40 +0200, Armin Steinhoff wrote:
> Hi,
> 
> when I read all these confusing statements here ( in german it looks 
> like an "Eiertanz")  ... I can only say:
> 
> - do the basic stuff in a minimal kernel driver
> - use UIO (or VFIO for PCI devices)

I see no requirement for any of those horrid things to be used. You can
write a full on proper kernel driver, it just cannot set kernel thread
priorities to a sane value (let them all default to 50 or so).

Then have a user space script or whatever set the kthread priorities.

> and you get clean control about your real-time priorities.
> 
> I think changing the priorities of "interrupt threads" inside the kernel 
> could lead to strange race conditions in the kernel.

No, changing the priority in the kernel is a perfectly sound operation,
it just doesn't make any sense to do so since its impossible to
determine a proper priority.

Therefore setting a priority is a pure user policy and should not be
done by the driver itself -- it simply cannot do it right so why bother
doing it.




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

* Re: Changing Kernel thread priorities
  2011-06-07  8:40             ` Monica Puig-Pey
@ 2011-06-07  9:14               ` Mark Hounschell
  2011-06-07  9:46                 ` Mark Hounschell
  0 siblings, 1 reply; 33+ messages in thread
From: Mark Hounschell @ 2011-06-07  9:14 UTC (permalink / raw)
  To: Monica Puig-Pey; +Cc: markh, Rolando Martins, linux-rt-users, linux-kernel

On 06/07/2011 04:40 AM, Monica Puig-Pey wrote:
> El 06/06/11 18:49, Mark Hounschell escribió:
>> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>>> El 06/06/11 13:54, Rolando Martins escribió:
>>>> Hi,
>>>> I use the following:
>>>>
>>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>>> print $1; }' | xargs echo)
>>>> for i in $PIDs
>>>> do
>>>> ret=$(chrt -f -p 99 $i)
>>>> done
>>>>
>>>> This will change the kernel thread associated with an irq handler to
>>>> RT FIFO prio 99.
>>>> Just change the script to your specific interrupt.
>>>>
>>>> Hope it helps,
>>>> Rolando
>>>>
>>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>>> wrote:
>>>>> I am writing a driver which has one kernel thread associated with it.
>>>>> I want to change the priority of this thread, so that I can specify the
>>>>> order in which it is scheduled following an interrupt.
>>>>> I'm using:
>>>>>
>>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>>
>>>>> but it doesn't work. I tried to change the priority from the
>>>>> init_module,
>>>>> and also from the Kernel Thread, but there is no way.
>>>>>
>>>>> Kernel version is 2.6.31-11-rt
>>>>>
>>>>> What do I call to change a kernel thread priority?
>>>>>
>>>>> Thanks you very much
>>>>>
>>>>> Mónica
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-rt-users" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>
>>> I need to change the priority from inside the driver, when creating the
>>> kernel thread.
>>> Your script is useful but it is done in user context,
>>> Any other help please?
>>
>> What I do is record the PID of the thread in the driver, then create an
>> IOCTL for your driver that user land can call that either returns the
>> PID so you can do it in user land, or cause the IOCTL code to do it in
>> the driver.
>>
>> The same can be done with the affinity of the IRQ if you record the IRQ
>> number.
>>
>> Mark
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> But I don't have de PID of my Kthread, I only have the task_struc * that
> gives me the function:
>
> struct task_struct *kthread_create(int (*threadfn)(void *data),
> void *data,
> const char namefmt[], ...)
>
> How could I get the PID, and which function should I use in the IOCTL
> (kernel context) for changing its priority?
>

The PID can be obtained from within the interrupt handler its self via 
current->pid.
Obviously an interrupt has to occur first but after one interrupt you have it.

Actually I had forgot how I handled this. Where I change the RT priority 
and cpu affinity is in what used to be called the Bottom Half and the IOCTL 
referred to above simply tells the BH to do it and with what values.

Regards
Mark




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

* Re: Changing Kernel thread priorities
  2011-06-07  8:27 Changing Kernel thread priorities Johannes Bauer
@ 2011-06-07  8:41 ` Thomas Gleixner
  2011-06-07  9:40   ` Armin Steinhoff
  0 siblings, 1 reply; 33+ messages in thread
From: Thomas Gleixner @ 2011-06-07  8:41 UTC (permalink / raw)
  To: Johannes Bauer
  Cc: Peter Zijlstra, Monica Puig-Pey, Rolando Martins, linux-rt-users,
	linux-kernel

On Tue, 7 Jun 2011, Johannes Bauer wrote:

Please stop top-posting and use proper line breaks at 78

> > Peter Zijlstra wrote:
> > > "Monica Puig-Pey" wrote:

> > > I need to change the priority from inside the driver, when creating the 
> > > kernel thread.
> >
> > No you don't. How does you driver know about what priority is correct
> > wrt all the other running RT tasks on the system?
> > 
> > Determining the right priority in a fixed priority scheduling system is
> > a system wide problem, nobody but the administrator can possibly even
> > begin to solve it.
> > 
> > There's a reason all RT irq threads are started at 50, its plain
> > impossible to do better.

> Absolutly correct!
> 
> However, if you are running the system on an embedded platform,
> where the _WHOLE_ system (including priorities) is preconfigured and
> never touched, starting a irq thread with the right prio from start
> is a more straightforward method than having to invoke a script that
> changes it using userspace chrt tool.

Feel free to do that for your embedded system and carry the patch for
yourself if you think it's worth to avoid the extra init script.

But we do _not_ add stuff like this to the mainline simply because
there is no way to find a prio setting which is appropriate for all
users of a particular driver.

Aside of that the extra init script is definitely less annoying to
maintain than the crap you need to hack into random drivers.

Thanks,

	tglx

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

* Re: Changing Kernel thread priorities
  2011-06-06 16:49           ` Mark Hounschell
@ 2011-06-07  8:40             ` Monica Puig-Pey
  2011-06-07  9:14               ` Mark Hounschell
  0 siblings, 1 reply; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-07  8:40 UTC (permalink / raw)
  To: markh; +Cc: Rolando Martins, linux-rt-users, linux-kernel

El 06/06/11 18:49, Mark Hounschell escribió:
> On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
>> El 06/06/11 13:54, Rolando Martins escribió:
>>> Hi,
>>> I use the following:
>>>
>>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>>> print $1; }' | xargs echo)
>>> for i in $PIDs
>>> do
>>> ret=$(chrt -f -p 99 $i)
>>> done
>>>
>>> This will change the kernel thread associated with an irq handler to
>>> RT FIFO prio 99.
>>> Just change the script to your specific interrupt.
>>>
>>> Hope it helps,
>>> Rolando
>>>
>>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>>> wrote:
>>>> I am writing a driver which has one kernel thread associated with it.
>>>> I want to change the priority of this thread, so that I can specify the
>>>> order in which it is scheduled following an interrupt.
>>>> I'm using:
>>>>
>>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>>
>>>> but it doesn't work. I tried to change the priority from the
>>>> init_module,
>>>> and also from the Kernel Thread, but there is no way.
>>>>
>>>> Kernel version is 2.6.31-11-rt
>>>>
>>>> What do I call to change a kernel thread priority?
>>>>
>>>> Thanks you very much
>>>>
>>>> Mónica
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>
>> I need to change the priority from inside the driver, when creating the
>> kernel thread.
>> Your script is useful but it is done in user context,
>> Any other help please?
>
> What I do is record the PID of the thread in the driver, then create an
> IOCTL for your driver that user land can call that either returns the
> PID so you can do it in user land, or cause the IOCTL code to do it in
> the driver.
>
> The same can be done with the affinity of the IRQ if you record the IRQ
> number.
>
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

But I don't have de PID of my Kthread, I only have the task_struc * that 
gives me the function:

  struct task_struct *kthread_create(int (*threadfn)(void *data),
                    void *data,
                    const char namefmt[], ...)

How could I get the PID, and which function should I use in the IOCTL 
(kernel context) for changing its priority?

Thank you so much for your help

Mónica

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

* Re: Changing Kernel thread priorities
@ 2011-06-07  8:27 Johannes Bauer
  2011-06-07  8:41 ` Thomas Gleixner
  0 siblings, 1 reply; 33+ messages in thread
From: Johannes Bauer @ 2011-06-07  8:27 UTC (permalink / raw)
  To: Peter Zijlstra, hannes_bauer
  Cc: Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel, tglx

Absolutly correct!

However, if you are running the system on an embedded platform, where the _WHOLE_ system (including priorities) is preconfigured and never touched, starting a irq thread with the right prio from start is a more straightforward method than having to invoke a script that changes it using userspace chrt tool.

Regards JB
----- Ursprüngliche Nachricht -----
Von: "Peter Zijlstra" <peterz@infradead.org>
Erhalten: 07.06.2011 00:36
An: hannes_bauer@aon.at

"Monica Puig-Pey" wrote:
> 
> I need to change the priority from inside the driver, when creating the 
> kernel thread.

No you don't. How does you driver know about what priority is correct
wrt all the other running RT tasks on the system?

Determining the right priority in a fixed priority scheduling system is
a system wide problem, nobody but the administrator can possibly even
begin to solve it.

There's a reason all RT irq threads are started at 50, its plain
impossible to do better.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

* Re: Changing Kernel thread priorities
  2011-06-06 12:10 Johannes Bauer
@ 2011-06-06 22:36 ` Peter Zijlstra
  0 siblings, 0 replies; 33+ messages in thread
From: Peter Zijlstra @ 2011-06-06 22:36 UTC (permalink / raw)
  To: hannes_bauer
  Cc: Monica Puig-Pey, Rolando Martins, linux-rt-users, linux-kernel, tglx

"Monica Puig-Pey" <puigpeym@unican.es> wrote:
> 
> I need to change the priority from inside the driver, when creating the 
> kernel thread.

No you don't. How does you driver know about what priority is correct
wrt all the other running RT tasks on the system?

Determining the right priority in a fixed priority scheduling system is
a system wide problem, nobody but the administrator can possibly even
begin to solve it.

There's a reason all RT irq threads are started at 50, its plain
impossible to do better.


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

* Re: Changing Kernel thread priorities
  2011-06-06 11:47     ` Changing Kernel thread priorities Monica Puig-Pey
  2011-06-06 11:54       ` Rolando Martins
@ 2011-06-06 18:20       ` Armin Steinhoff
  1 sibling, 0 replies; 33+ messages in thread
From: Armin Steinhoff @ 2011-06-06 18:20 UTC (permalink / raw)
  To: Monica Puig-Pey; +Cc: linux-rt-users, linux-kernel

Monica Puig-Pey wrote:
> I am writing a driver which has one kernel thread associated with it.
> I want to change the priority of this thread, so that I can specify 
> the order in which it is scheduled following an interrupt.
> I'm using:
>
>  sched_setscheduler(struct task_struct *, int, struct sched_param *);  
> -> sys_sched_setscheduler

http://ftp.au.debian.org/linux-mandocs/2.6.0-test7-full/sys_sched_setscheduler.html

Hope this helps ..

--Armin

>
> but it doesn't work. I tried to change the priority from the 
> init_module, and also from the Kernel Thread, but there is no way.
>
> Kernel version is 2.6.31-11-rt
>
> What do I call to change a kernel thread priority?
>
> Thanks you very much
>
> Mónica
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


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

* Re: Changing Kernel thread priorities
  2011-06-06 11:58         ` Monica Puig-Pey
@ 2011-06-06 16:49           ` Mark Hounschell
  2011-06-07  8:40             ` Monica Puig-Pey
  0 siblings, 1 reply; 33+ messages in thread
From: Mark Hounschell @ 2011-06-06 16:49 UTC (permalink / raw)
  To: Monica Puig-Pey; +Cc: Rolando Martins, linux-rt-users, linux-kernel

On 06/06/2011 07:58 AM, Monica Puig-Pey wrote:
> El 06/06/11 13:54, Rolando Martins escribió:
>> Hi,
>> I use the following:
>>
>> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
>> print $1; }' | xargs echo)
>> for i in $PIDs
>> do
>> ret=$(chrt -f -p 99 $i)
>> done
>>
>> This will change the kernel thread associated with an irq handler to
>> RT FIFO prio 99.
>> Just change the script to your specific interrupt.
>>
>> Hope it helps,
>> Rolando
>>
>> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>
>> wrote:
>>> I am writing a driver which has one kernel thread associated with it.
>>> I want to change the priority of this thread, so that I can specify the
>>> order in which it is scheduled following an interrupt.
>>> I'm using:
>>>
>>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>>
>>> but it doesn't work. I tried to change the priority from the
>>> init_module,
>>> and also from the Kernel Thread, but there is no way.
>>>
>>> Kernel version is 2.6.31-11-rt
>>>
>>> What do I call to change a kernel thread priority?
>>>
>>> Thanks you very much
>>>
>>> Mónica
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-rt-users" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
> I need to change the priority from inside the driver, when creating the
> kernel thread.
> Your script is useful but it is done in user context,
> Any other help please?

What I do is record the PID of the thread in the driver, then create an 
IOCTL for your driver that user land can call that either returns the 
PID so you can do it in user land, or cause the IOCTL code to do it in 
the driver.

The same can be done with the affinity of the IRQ if you record the IRQ 
number.

Mark

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

* Re: Changing Kernel thread priorities
@ 2011-06-06 12:10 Johannes Bauer
  2011-06-06 22:36 ` Peter Zijlstra
  0 siblings, 1 reply; 33+ messages in thread
From: Johannes Bauer @ 2011-06-06 12:10 UTC (permalink / raw)
  To: Monica Puig-Pey, Rolando Martins; +Cc: linux-rt-users, linux-kernel

Hi!

i thought i sent you the discussion already...

But again, here is how Remy Bohmer does it using the same sched_setscheduler call!
http://www.mail-archive.com/linux-rt-users@vger.kernel.org/msg01046.html

If it does not help you, i woul dsuggest to post your code, maybe this would help people to help you...

regards JB



----- Ursprüngliche Nachricht -----
Von: "Monica Puig-Pey" <puigpeym@unican.es>
Erhalten: 06.06.2011 13:58
An: "Rolando Martins" <rolando.martins@gmail.com>

El 06/06/11 13:54, Rolando Martins escribió:
> Hi,
> I use the following:
>
> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
> print $1; }' | xargs echo)
> for i in $PIDs
> do
> ret=$(chrt -f -p 99 $i)
> done
>
> This will change the kernel thread associated with an irq handler to
> RT FIFO prio 99.
> Just change the script to your specific interrupt.
>
> Hope it helps,
> Rolando
>
> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey wrote:
>> I am writing a driver which has one kernel thread associated with it.
>> I want to change the priority of this thread, so that I can specify the
>> order in which it is scheduled following an interrupt.
>> I'm using:
>>
>> sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>
>> but it doesn't work. I tried to change the priority from the init_module,
>> and also from the Kernel Thread, but there is no way.
>>
>> Kernel version is 2.6.31-11-rt
>>
>> What do I call to change a kernel thread priority?
>>
>> Thanks you very much
>>
>> Mónica
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>

I need to change the priority from inside the driver, when creating the 
kernel thread.
Your script is useful but it is done in user context,
Any other help please?

Mónica


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

* Re: Changing Kernel thread priorities
  2011-06-06 11:54       ` Rolando Martins
@ 2011-06-06 11:58         ` Monica Puig-Pey
  2011-06-06 16:49           ` Mark Hounschell
  0 siblings, 1 reply; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-06 11:58 UTC (permalink / raw)
  To: Rolando Martins; +Cc: linux-rt-users, linux-kernel

El 06/06/11 13:54, Rolando Martins escribió:
> Hi,
> I use the following:
>
> PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
> print $1; }' | xargs echo)
> for i in $PIDs
> do
>      ret=$(chrt -f -p 99 $i)
> done
>
> This will change the kernel thread associated with an irq handler to
> RT FIFO prio 99.
> Just change the script to your specific interrupt.
>
> Hope it helps,
> Rolando
>
> On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey<puigpeym@unican.es>  wrote:
>> I am writing a driver which has one kernel thread associated with it.
>> I want to change the priority of this thread, so that I can specify the
>> order in which it is scheduled following an interrupt.
>> I'm using:
>>
>>   sched_setscheduler(struct task_struct *, int, struct sched_param *);
>>
>> but it doesn't work. I tried to change the priority from the init_module,
>> and also from the Kernel Thread, but there is no way.
>>
>> Kernel version is 2.6.31-11-rt
>>
>> What do I call to change a kernel thread priority?
>>
>> Thanks you very much
>>
>> Mónica
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

I need to change the priority from inside the driver, when creating the 
kernel thread.
Your script is useful but it is done in user context,
Any other help please?

Mónica



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

* Re: Changing Kernel thread priorities
  2011-06-06 11:47     ` Changing Kernel thread priorities Monica Puig-Pey
@ 2011-06-06 11:54       ` Rolando Martins
  2011-06-06 11:58         ` Monica Puig-Pey
  2011-06-06 18:20       ` Armin Steinhoff
  1 sibling, 1 reply; 33+ messages in thread
From: Rolando Martins @ 2011-06-06 11:54 UTC (permalink / raw)
  To: Monica Puig-Pey; +Cc: linux-rt-users, linux-kernel

Hi,
I use the following:

PIDs=$(ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq" | awk '{
print $1; }' | xargs echo)
for i in $PIDs
do
    ret=$(chrt -f -p 99 $i)
done

This will change the kernel thread associated with an irq handler to
RT FIFO prio 99.
Just change the script to your specific interrupt.

Hope it helps,
Rolando

On Mon, Jun 6, 2011 at 12:47 PM, Monica Puig-Pey <puigpeym@unican.es> wrote:
> I am writing a driver which has one kernel thread associated with it.
> I want to change the priority of this thread, so that I can specify the
> order in which it is scheduled following an interrupt.
> I'm using:
>
>  sched_setscheduler(struct task_struct *, int, struct sched_param *);
>
> but it doesn't work. I tried to change the priority from the init_module,
> and also from the Kernel Thread, but there is no way.
>
> Kernel version is 2.6.31-11-rt
>
> What do I call to change a kernel thread priority?
>
> Thanks you very much
>
> Mónica
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

* Changing Kernel thread priorities
  2011-06-04 12:30   ` kernel threads in drivers using the RT patch Monica Puig-Pey
@ 2011-06-06 11:47     ` Monica Puig-Pey
  2011-06-06 11:54       ` Rolando Martins
  2011-06-06 18:20       ` Armin Steinhoff
  0 siblings, 2 replies; 33+ messages in thread
From: Monica Puig-Pey @ 2011-06-06 11:47 UTC (permalink / raw)
  To: linux-rt-users, linux-kernel

I am writing a driver which has one kernel thread associated with it.
I want to change the priority of this thread, so that I can specify the 
order in which it is scheduled following an interrupt.
I'm using:

  sched_setscheduler(struct task_struct *, int, struct sched_param *);

but it doesn't work. I tried to change the priority from the 
init_module, and also from the Kernel Thread, but there is no way.

Kernel version is 2.6.31-11-rt

What do I call to change a kernel thread priority?

Thanks you very much

Mónica


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

end of thread, other threads:[~2011-06-11 17:39 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <17185480.5304.1307435255996.JavaMail.root@WARSBL214.highway.tel ekom.at>
     [not found] ` <17185480.5304.1307435255996.JavaMail.root@WARSBL214.highway.te lekom.at>
2011-06-07  8:32   ` Changing Kernel thread priorities Monica Puig-Pey
2011-06-07  8:43     ` Thomas Gleixner
2011-06-07 21:28       ` Threaded Irqs (was "Changing Kernel thread priorities") Tim Sander
2011-06-07 21:56         ` Thomas Gleixner
2011-06-07  8:27 Changing Kernel thread priorities Johannes Bauer
2011-06-07  8:41 ` Thomas Gleixner
2011-06-07  9:40   ` Armin Steinhoff
2011-06-07  9:37     ` Peter Zijlstra
2011-06-07 11:02       ` Remy Bohmer
2011-06-07 14:14         ` Peter Zijlstra
2011-06-07 14:57           ` Lucas De Marchi
2011-06-07 15:15           ` Thomas Gleixner
2011-06-07 23:38             ` Nicholas Mc Guire
2011-06-07 23:35         ` Nicholas Mc Guire
2011-06-08 17:50           ` Remy Bohmer
2011-06-08 19:49             ` Thomas Gleixner
2011-06-10 14:04               ` Remy Bohmer
2011-06-10 15:37                 ` Thomas Gleixner
2011-06-11 17:16                   ` Remy Bohmer
2011-06-09 11:19             ` Nicholas Mc Guire
  -- strict thread matches above, loose matches on Subject: below --
2011-06-06 12:10 Johannes Bauer
2011-06-06 22:36 ` Peter Zijlstra
2011-06-04 11:48 One Interrupted Threads per Interrupt line? Monica Puig-Pey
2011-06-04 12:03 ` I/O operations priority in RTOS Monica Puig-Pey
2011-06-04 12:30   ` kernel threads in drivers using the RT patch Monica Puig-Pey
2011-06-06 11:47     ` Changing Kernel thread priorities Monica Puig-Pey
2011-06-06 11:54       ` Rolando Martins
2011-06-06 11:58         ` Monica Puig-Pey
2011-06-06 16:49           ` Mark Hounschell
2011-06-07  8:40             ` Monica Puig-Pey
2011-06-07  9:14               ` Mark Hounschell
2011-06-07  9:46                 ` Mark Hounschell
2011-06-07 18:34                   ` Monica Puig-Pey
2011-06-07 18:55                     ` Mark Hounschell
2011-06-10 10:12                       ` Monica Puig-Pey
2011-06-06 18:20       ` Armin Steinhoff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).