* Ingo's realtime_preempt patch causes kernel oops @ 2006-05-23 13:40 Yann.LEPROVOST 2006-05-23 14:09 ` Steven Rostedt 2006-05-23 14:19 ` Steven Rostedt 0 siblings, 2 replies; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-23 13:40 UTC (permalink / raw) To: linux-kernel Hi all, I applied last Ingo Molnar's realtime_preempt patch (-rt23) on a vanilla 2.6.16 kernel. My architecture is an ARM based CSB637 evaluation board from Cogent. I obtain the following kernel oops : Uncompressing Linux............................................... done, booting the kernel. Linux version 2.6.16-rt23 (yleprovost@wmp-ylplinux) (gcc version 3.4.4) #1 PREEMPT Tue May 23 15:24:21 CEST 2006 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Cogent CSB637 Warning: bad configuration page, trying to continue Memory policy: ECC disabled, Data cache writeback Clocks: CPU 184 MHz, master 46 MHz, main 3.686 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Real-Time Preemption Support (C) 2004-2006 Ingo Molnar Built 1 zonelists Kernel command line: mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 root=/dev/ram0 rw WARNING: experimental RCU implementation. AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 27828KB available (1100K code, 324K data, 76K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Unable to handle kernel NULL pointer dereference at virtual address 00000040 pgd = c0004000 [00000040] *pgd=00000000 Internal error: Oops: 5 [#1] Modules linked in: CPU: 0 PC is at profile_tick+0x34/0xa4 LR is at timer_tick+0x1c/0xe4 pc : [<c0032724>] lr : [<c001fd34>] Not tainted sp : c0409f04 ip : c0409f1c fp : c0409f18 r10: 00000000 r9 : 00000001 r8 : 00000000 r7 : 00000001 r6 : 00000000 r5 : 00000001 r4 : 00000000 r3 : 00000000 r2 : 000043ea r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: C000717F Table: 20004000 DAC: 00000017 Process IRQ 1 (pid: 2, stack limit = 0xc0408198) Stack: (0xc0409f04 to 0xc040a000) 9f00: 00000000 c016eaf0 c0409f34 c0409f1c c001fd34 c0032700 fefff000 9f20: c016eaf0 00000000 c0409f50 c0409f38 c0025030 c001fd28 c0139a58 c0408000 9f40: 00000000 c0409f80 c0409f54 c0053024 c0024fd4 00000000 00000000 c01320c0 9f60: c0139a58 00000001 fffffffc 00000000 00000000 c0409fa0 c0409f84 c0053c80 9f80: c0052fcc c0132040 c01320c0 c0405edc c0408000 c0409fc4 c0409fa4 c0053db0 9fa0: c0053c30 00000031 c01320c0 c0408000 c0405edc c0053cdc c0409ff4 c0409fc8 9fc0: c00463ac c0053cec 00000001 ffffffff ffffffff 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 c0409ff8 c00338e0 c00462cc 6fdb904a ff3b1884 Backtrace: [<c00326f0>] (profile_tick+0x0/0xa4) from [<c001fd34>] (timer_tick+0x1c/0xe4) r5 = C016EAF0 r4 = 00000000 [<c001fd18>] (timer_tick+0x0/0xe4) from [<c0025030>] (at91rm9200_timer_interrupt+0x6c/0xbc) r6 = 00000000 r5 = C016EAF0 r4 = FEFFF000 [<c0024fc4>] (at91rm9200_timer_interrupt+0x0/0xbc) from [<c0053024>] (handle_IRQ_event+0x68/0xf0) r6 = 00000000 r5 = C0408000 r4 = C0139A58 [<c0052fbc>] (handle_IRQ_event+0x0/0xf0) from [<c0053c80>] (thread_simple_irq+0x60/0xbc) [<c0053c20>] (thread_simple_irq+0x0/0xbc) from [<c0053db0>] (do_irqd+0xd4/0x278) r7 = C0408000 r6 = C0405EDC r5 = C01320C0 r4 = C0132040 [<c0053cdc>] (do_irqd+0x0/0x278) from [<c00463ac>] (kthread+0xf0/0x120) r7 = C0053CDC r6 = C0405EDC r5 = C0408000 r4 = C01320C0 [<c00462bc>] (kthread+0x0/0x120) from [<c00338e0>] (do_exit+0x0/0x8bc) r8 = 00000000 r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000 Code: e5933000 e3530000 11a0e00f 11a0f003 (e5943040) <6>note: IRQ 1[2] exited with preempt_count 1 BUG: scheduling while atomic: IRQ 1/0x00000001/2 caller is do_exit+0x838/0x8bc prev->state: 2 != TASK_RUNNING?? IRQ 1/2[CPU#0]: BUG in __schedule at kernel/sched.c:3382 < ..... Then kernel freezes .....> This appears only when CONFIG_PREEMPT_HARDIRQS is enabled. The last trace is obtained using CONFIG_RT_PREEMPT which forces CONFIG_PREEMPT_HARDIRQS to "yes". For others configurations, when PREEMPT_HARDIRQS is disabled, it works great. It seems to be something dealing with bad irq returns when hardirq serializing is enabled ?!? Has anyone had ever seen this oops before ? Any clue to solve that ? Regards Yann Leprovost Here is my current .config file : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.16-rt23 # Tue May 23 15:18:53 2006 # CONFIG_ARM=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_UID16=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_SLAB=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # System Type # # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_IOP3XX is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_OMAP is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_AAEC2000 is not set CONFIG_ARCH_AT91=y # # Atmel AT91 System-on-Chip # CONFIG_ARCH_AT91RM9200=y # # AT91RM9200 Board Type # # CONFIG_ARCH_AT91RM9200DK is not set # CONFIG_MACH_AT91RM9200EK is not set # CONFIG_MACH_CSB337 is not set CONFIG_MACH_CSB637=y # CONFIG_MACH_CARMEVA is not set # CONFIG_MACH_KB9200 is not set # CONFIG_MACH_ATEB9200 is not set # CONFIG_MACH_KAFA is not set # CONFIG_ARCH_AT91SAM9261 is not set # # AT91 Feature Selections # CONFIG_AT91_PROGRAMMABLE_CLOCKS=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_ARM920T=y CONFIG_CPU_32v4=y CONFIG_CPU_ABRT_EV4T=y CONFIG_CPU_CACHE_V4WT=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_COPY_V4WB=y CONFIG_CPU_TLB_V4WBI=y # # Processor Features # # CONFIG_ARM_THUMB is not set # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_DCACHE_WRITETHROUGH is not set # # Bus support # # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y # # PC-card bridges # CONFIG_AT91_CF=y # # Kernel Features # # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_STATS=y # CONFIG_NO_IDLE_HZ is not set # CONFIG_AEABI is not set # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4096 # CONFIG_LEDS is not set CONFIG_ALIGNMENT_TRAP=y # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 root=/dev/ram0 rw" # CONFIG_XIP_KERNEL is not set # # Floating point emulation # # # At least one emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set # # Userspace binary formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # CONFIG_ARTHUR is not set # # Power management options # # CONFIG_PM is not set # CONFIG_APM is not set # # Networking # # CONFIG_NET is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # # Connector - unified userspace <-> kernelspace linker # # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # # # Block devices # # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_INITRD=y # CONFIG_CDROM_PKTCDVD is not set # # ATA/ATAPI/MFM/RLL support # # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # # CONFIG_BLK_DEV_SD is not set # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # # SCSI low-level drivers # # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # I2O device support # # # ISDN subsystem # # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_AT91=y CONFIG_SERIAL_AT91_CONSOLE=y # CONFIG_SERIAL_AT91_TTYAT is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set CONFIG_AT91_WATCHDOG=y # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_RTC_HISTOGRAM is not set # CONFIG_AT91_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # # Ftape, the floppy tape device driver # # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_RAW_DRIVER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_AT91_SPI=y CONFIG_AT91_SPIDEV=y # # I2C support # # CONFIG_I2C is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Hardware Monitoring support # # CONFIG_HWMON is not set # CONFIG_HWMON_VID is not set # # Misc devices # # # Multimedia Capabilities Port drivers # # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # # Graphics support # # CONFIG_FB is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # CONFIG_USB is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set # CONFIG_EXT3_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # # CONFIG_MSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_RELAYFS_FS is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=y # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # # CONFIG_NLS is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # # CONFIG_PRINTK_TIME is not set # CONFIG_PRINTK_IGNORE_LOGLEVEL is not set # CONFIG_MAGIC_SYSRQ is not set CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set CONFIG_WAKEUP_TIMING=y # CONFIG_WAKEUP_LATENCY_HIST is not set CONFIG_PREEMPT_TRACE=y # CONFIG_CRITICAL_PREEMPT_TIMING is not set # CONFIG_CRITICAL_IRQSOFF_TIMING is not set CONFIG_LATENCY_TIMING=y # CONFIG_LATENCY_TRACE is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_FS is not set # CONFIG_DEBUG_VM is not set CONFIG_FORCED_INLINING=y CONFIG_FRAME_POINTER=y # CONFIG_RCU_TORTURE_TEST is not set CONFIG_DEBUG_USER=y # CONFIG_DEBUG_WAITQ is not set # CONFIG_DEBUG_ERRORS is not set CONFIG_DEBUG_LL=y # CONFIG_DEBUG_ICEDCC is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # # Library routines # # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_PLIST=y ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 13:40 Ingo's realtime_preempt patch causes kernel oops Yann.LEPROVOST @ 2006-05-23 14:09 ` Steven Rostedt 2006-05-23 14:19 ` Steven Rostedt 1 sibling, 0 replies; 34+ messages in thread From: Steven Rostedt @ 2006-05-23 14:09 UTC (permalink / raw) To: Yann.LEPROVOST; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar I just CC'd Thomas Gleixner on this, because he does a lot of arm for the -rt patch, as well as included Ingo Molnar since he is the maintainer. On Tue, 2006-05-23 at 15:40 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Hi all, > > I applied last Ingo Molnar's realtime_preempt patch (-rt23) on a vanilla > 2.6.16 kernel. > My architecture is an ARM based CSB637 evaluation board from Cogent. > > I obtain the following kernel oops : > > Uncompressing Linux............................................... done, > booting the kernel. > Linux version 2.6.16-rt23 (yleprovost@wmp-ylplinux) (gcc version 3.4.4) #1 > PREEMPT Tue May 23 15:24:21 CEST 2006 > CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) > Machine: Cogent CSB637 > Warning: bad configuration page, trying to continue > Memory policy: ECC disabled, Data cache writeback > Clocks: CPU 184 MHz, master 46 MHz, main 3.686 MHz > CPU0: D VIVT write-back cache > CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > Real-Time Preemption Support (C) 2004-2006 Ingo Molnar > Built 1 zonelists > Kernel command line: mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 > root=/dev/ram0 rw > WARNING: experimental RCU implementation. > AT91: 128 gpio irqs in 4 banks > PID hash table entries: 256 (order: 8, 4096 bytes) > Console: colour dummy device 80x30 > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Memory: 32MB = 32MB total > Memory: 27828KB available (1100K code, 324K data, 76K init) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > Unable to handle kernel NULL pointer dereference at virtual address > 00000040 > pgd = c0004000 > [00000040] *pgd=00000000 > Internal error: Oops: 5 [#1] > Modules linked in: > CPU: 0 > PC is at profile_tick+0x34/0xa4 > LR is at timer_tick+0x1c/0xe4 > pc : [<c0032724>] lr : [<c001fd34>] Not tainted > sp : c0409f04 ip : c0409f1c fp : c0409f18 > r10: 00000000 r9 : 00000001 r8 : 00000000 > r7 : 00000001 r6 : 00000000 r5 : 00000001 r4 : 00000000 > r3 : 00000000 r2 : 000043ea r1 : 00000000 r0 : 00000000 > Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel > Control: C000717F Table: 20004000 DAC: 00000017 > Process IRQ 1 (pid: 2, stack limit = 0xc0408198) > Stack: (0xc0409f04 to 0xc040a000) > 9f00: 00000000 c016eaf0 c0409f34 c0409f1c c001fd34 c0032700 > fefff000 > 9f20: c016eaf0 00000000 c0409f50 c0409f38 c0025030 c001fd28 c0139a58 > c0408000 > 9f40: 00000000 c0409f80 c0409f54 c0053024 c0024fd4 00000000 00000000 > c01320c0 > 9f60: c0139a58 00000001 fffffffc 00000000 00000000 c0409fa0 c0409f84 > c0053c80 > 9f80: c0052fcc c0132040 c01320c0 c0405edc c0408000 c0409fc4 c0409fa4 > c0053db0 > 9fa0: c0053c30 00000031 c01320c0 c0408000 c0405edc c0053cdc c0409ff4 > c0409fc8 > 9fc0: c00463ac c0053cec 00000001 ffffffff ffffffff 00000000 00000000 > 00000000 > 9fe0: 00000000 00000000 00000000 c0409ff8 c00338e0 c00462cc 6fdb904a > ff3b1884 > Backtrace: > [<c00326f0>] (profile_tick+0x0/0xa4) from [<c001fd34>] > (timer_tick+0x1c/0xe4) > r5 = C016EAF0 r4 = 00000000 > [<c001fd18>] (timer_tick+0x0/0xe4) from [<c0025030>] > (at91rm9200_timer_interrupt+0x6c/0xbc) The above does look arm specific. > r6 = 00000000 r5 = C016EAF0 r4 = FEFFF000 > [<c0024fc4>] (at91rm9200_timer_interrupt+0x0/0xbc) from [<c0053024>] > (handle_IRQ_event+0x68/0xf0) > r6 = 00000000 r5 = C0408000 r4 = C0139A58 > [<c0052fbc>] (handle_IRQ_event+0x0/0xf0) from [<c0053c80>] > (thread_simple_irq+0x60/0xbc) > [<c0053c20>] (thread_simple_irq+0x0/0xbc) from [<c0053db0>] > (do_irqd+0xd4/0x278) > r7 = C0408000 r6 = C0405EDC r5 = C01320C0 r4 = C0132040 > [<c0053cdc>] (do_irqd+0x0/0x278) from [<c00463ac>] (kthread+0xf0/0x120) > r7 = C0053CDC r6 = C0405EDC r5 = C0408000 r4 = C01320C0 > [<c00462bc>] (kthread+0x0/0x120) from [<c00338e0>] (do_exit+0x0/0x8bc) > r8 = 00000000 r7 = 00000000 r6 = 00000000 r5 = 00000000 > r4 = 00000000 > Code: e5933000 e3530000 11a0e00f 11a0f003 (e5943040) > <6>note: IRQ 1[2] exited with preempt_count 1 > BUG: scheduling while atomic: IRQ 1/0x00000001/2 > caller is do_exit+0x838/0x8bc > prev->state: 2 != TASK_RUNNING?? > IRQ 1/2[CPU#0]: BUG in __schedule at kernel/sched.c:3382 > > < ..... Then kernel freezes .....> > > This appears only when CONFIG_PREEMPT_HARDIRQS is enabled. Thomas, The fault is at 0x40 and looking at profile_tick it calls user_mode(regs). user_mode(x) is defined in arm as (((regs)->ARM_cpsr & 0xf) == 0) And ARM_cpsr is uregs[16] So if arm has 4 byte words and regs was NULL, it would fault on 16*4 = 64 or 0x40 It looks like the timer interrupt on this board is having a NULL regs passed to it when hard interrupts are threads. Which might mean that the timer interrupt is itself a thread. -- Steve > The last trace is obtained using CONFIG_RT_PREEMPT which forces > CONFIG_PREEMPT_HARDIRQS to "yes". > For others configurations, when PREEMPT_HARDIRQS is disabled, it works > great. > > It seems to be something dealing with bad irq returns when hardirq > serializing is enabled ?!? > > Has anyone had ever seen this oops before ? > Any clue to solve that ? > > Regards > > Yann Leprovost > > > Here is my current .config file : > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.16-rt23 > # Tue May 23 15:18:53 2006 > # > CONFIG_ARM=y > CONFIG_MMU=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_RWSEM_GENERIC_SPINLOCK=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > # > # General setup > # > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_IKCONFIG is not set > CONFIG_INITRAMFS_SOURCE="" > CONFIG_UID16=y > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > # CONFIG_EMBEDDED is not set > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_RT_MUTEXES=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > CONFIG_SHMEM=y > CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > # CONFIG_SLOB is not set > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > CONFIG_OBSOLETE_MODPARM=y > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > CONFIG_KMOD=y > > # > # Block layer > # > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > CONFIG_DEFAULT_AS=y > # CONFIG_DEFAULT_DEADLINE is not set > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="anticipatory" > > # > # System Type > # > # CONFIG_ARCH_CLPS7500 is not set > # CONFIG_ARCH_CLPS711X is not set > # CONFIG_ARCH_CO285 is not set > # CONFIG_ARCH_EBSA110 is not set > # CONFIG_ARCH_FOOTBRIDGE is not set > # CONFIG_ARCH_INTEGRATOR is not set > # CONFIG_ARCH_IOP3XX is not set > # CONFIG_ARCH_IXP4XX is not set > # CONFIG_ARCH_IXP2000 is not set > # CONFIG_ARCH_L7200 is not set > # CONFIG_ARCH_PXA is not set > # CONFIG_ARCH_RPC is not set > # CONFIG_ARCH_SA1100 is not set > # CONFIG_ARCH_S3C2410 is not set > # CONFIG_ARCH_SHARK is not set > # CONFIG_ARCH_LH7A40X is not set > # CONFIG_ARCH_OMAP is not set > # CONFIG_ARCH_VERSATILE is not set > # CONFIG_ARCH_REALVIEW is not set > # CONFIG_ARCH_IMX is not set > # CONFIG_ARCH_H720X is not set > # CONFIG_ARCH_AAEC2000 is not set > CONFIG_ARCH_AT91=y > > # > # Atmel AT91 System-on-Chip > # > CONFIG_ARCH_AT91RM9200=y > > # > # AT91RM9200 Board Type > # > # CONFIG_ARCH_AT91RM9200DK is not set > # CONFIG_MACH_AT91RM9200EK is not set > # CONFIG_MACH_CSB337 is not set > CONFIG_MACH_CSB637=y > # CONFIG_MACH_CARMEVA is not set > # CONFIG_MACH_KB9200 is not set > # CONFIG_MACH_ATEB9200 is not set > # CONFIG_MACH_KAFA is not set > # CONFIG_ARCH_AT91SAM9261 is not set > > # > # AT91 Feature Selections > # > CONFIG_AT91_PROGRAMMABLE_CLOCKS=y > > # > # Processor Type > # > CONFIG_CPU_32=y > CONFIG_CPU_ARM920T=y > CONFIG_CPU_32v4=y > CONFIG_CPU_ABRT_EV4T=y > CONFIG_CPU_CACHE_V4WT=y > CONFIG_CPU_CACHE_VIVT=y > CONFIG_CPU_COPY_V4WB=y > CONFIG_CPU_TLB_V4WBI=y > > # > # Processor Features > # > # CONFIG_ARM_THUMB is not set > # CONFIG_CPU_ICACHE_DISABLE is not set > # CONFIG_CPU_DCACHE_DISABLE is not set > # CONFIG_CPU_DCACHE_WRITETHROUGH is not set > > # > # Bus support > # > > # > # PCCARD (PCMCIA/CardBus) support > # > CONFIG_PCCARD=y > # CONFIG_PCMCIA_DEBUG is not set > CONFIG_PCMCIA=y > CONFIG_PCMCIA_LOAD_CIS=y > CONFIG_PCMCIA_IOCTL=y > > # > # PC-card bridges > # > CONFIG_AT91_CF=y > > # > # Kernel Features > # > # CONFIG_PREEMPT_NONE is not set > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT_DESKTOP is not set > CONFIG_PREEMPT_RT=y > CONFIG_PREEMPT=y > CONFIG_PREEMPT_SOFTIRQS=y > CONFIG_PREEMPT_HARDIRQS=y > CONFIG_PREEMPT_BKL=y > # CONFIG_CLASSIC_RCU is not set > CONFIG_PREEMPT_RCU=y > CONFIG_RCU_STATS=y > # CONFIG_NO_IDLE_HZ is not set > # CONFIG_AEABI is not set > # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_MANUAL=y > # CONFIG_DISCONTIGMEM_MANUAL is not set > # CONFIG_SPARSEMEM_MANUAL is not set > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > # CONFIG_SPARSEMEM_STATIC is not set > CONFIG_SPLIT_PTLOCK_CPUS=4096 > # CONFIG_LEDS is not set > CONFIG_ALIGNMENT_TRAP=y > > # > # Boot options > # > CONFIG_ZBOOT_ROM_TEXT=0x0 > CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_CMDLINE="mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 > root=/dev/ram0 rw" > # CONFIG_XIP_KERNEL is not set > > # > # Floating point emulation > # > > # > # At least one emulation must be selected > # > CONFIG_FPE_NWFPE=y > # CONFIG_FPE_NWFPE_XP is not set > # CONFIG_FPE_FASTFPE is not set > > # > # Userspace binary formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > # CONFIG_ARTHUR is not set > > # > # Power management options > # > # CONFIG_PM is not set > # CONFIG_APM is not set > > # > # Networking > # > # CONFIG_NET is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > CONFIG_STANDALONE=y > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FW_LOADER=y > # CONFIG_DEBUG_DRIVER is not set > > # > # Connector - unified userspace <-> kernelspace linker > # > > # > # Memory Technology Devices (MTD) > # > # CONFIG_MTD is not set > > # > # Parallel port support > # > # CONFIG_PARPORT is not set > > # > # Plug and Play support > # > > # > # Block devices > # > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=y > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=16 > CONFIG_BLK_DEV_RAM_SIZE=8192 > CONFIG_BLK_DEV_INITRD=y > # CONFIG_CDROM_PKTCDVD is not set > > # > # ATA/ATAPI/MFM/RLL support > # > # CONFIG_IDE is not set > > # > # SCSI device support > # > # CONFIG_RAID_ATTRS is not set > CONFIG_SCSI=y > # CONFIG_SCSI_PROC_FS is not set > > # > # SCSI support type (disk, tape, CD-ROM) > # > # CONFIG_BLK_DEV_SD is not set > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > # CONFIG_BLK_DEV_SR is not set > # CONFIG_CHR_DEV_SG is not set > # CONFIG_CHR_DEV_SCH is not set > > # > # Some SCSI devices (e.g. CD jukebox) support multiple LUNs > # > # CONFIG_SCSI_MULTI_LUN is not set > # CONFIG_SCSI_CONSTANTS is not set > # CONFIG_SCSI_LOGGING is not set > > # > # SCSI Transport Attributes > # > # CONFIG_SCSI_SPI_ATTRS is not set > # CONFIG_SCSI_FC_ATTRS is not set > # CONFIG_SCSI_SAS_ATTRS is not set > > # > # SCSI low-level drivers > # > # CONFIG_SCSI_SATA is not set > # CONFIG_SCSI_DEBUG is not set > > # > # PCMCIA SCSI adapter support > # > # CONFIG_PCMCIA_AHA152X is not set > # CONFIG_PCMCIA_FDOMAIN is not set > # CONFIG_PCMCIA_NINJA_SCSI is not set > # CONFIG_PCMCIA_QLOGIC is not set > # CONFIG_PCMCIA_SYM53C500 is not set > > # > # Multi-device support (RAID and LVM) > # > # CONFIG_MD is not set > > # > # Fusion MPT device support > # > # CONFIG_FUSION is not set > > # > # IEEE 1394 (FireWire) support > # > > # > # I2O device support > # > > # > # ISDN subsystem > # > > # > # Input device support > # > CONFIG_INPUT=y > > # > # Userland interfaces > # > CONFIG_INPUT_MOUSEDEV=y > # CONFIG_INPUT_MOUSEDEV_PSAUX is not set > CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_TSDEV is not set > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input Device Drivers > # > # CONFIG_INPUT_KEYBOARD is not set > # CONFIG_INPUT_MOUSE is not set > # CONFIG_INPUT_JOYSTICK is not set > # CONFIG_INPUT_TOUCHSCREEN is not set > # CONFIG_INPUT_MISC is not set > > # > # Hardware I/O ports > # > # CONFIG_SERIO is not set > # CONFIG_GAMEPORT is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_HW_CONSOLE=y > # CONFIG_SERIAL_NONSTANDARD is not set > > # > # Serial drivers > # > # CONFIG_SERIAL_8250 is not set > > # > # Non-8250 serial port support > # > CONFIG_SERIAL_AT91=y > CONFIG_SERIAL_AT91_CONSOLE=y > # CONFIG_SERIAL_AT91_TTYAT is not set > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > CONFIG_UNIX98_PTYS=y > CONFIG_LEGACY_PTYS=y > CONFIG_LEGACY_PTY_COUNT=256 > > # > # IPMI > # > # CONFIG_IPMI_HANDLER is not set > > # > # Watchdog Cards > # > CONFIG_WATCHDOG=y > CONFIG_WATCHDOG_NOWAYOUT=y > > # > # Watchdog Device Drivers > # > # CONFIG_SOFT_WATCHDOG is not set > CONFIG_AT91_WATCHDOG=y > # CONFIG_NVRAM is not set > CONFIG_RTC=y > # CONFIG_RTC_HISTOGRAM is not set > # CONFIG_AT91_RTC is not set > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > > # > # Ftape, the floppy tape device driver > # > > # > # PCMCIA character devices > # > # CONFIG_SYNCLINK_CS is not set > # CONFIG_CARDMAN_4000 is not set > # CONFIG_CARDMAN_4040 is not set > # CONFIG_RAW_DRIVER is not set > > # > # TPM devices > # > # CONFIG_TCG_TPM is not set > # CONFIG_TELCLOCK is not set > CONFIG_AT91_SPI=y > CONFIG_AT91_SPIDEV=y > > # > # I2C support > # > # CONFIG_I2C is not set > > # > # SPI support > # > # CONFIG_SPI is not set > # CONFIG_SPI_MASTER is not set > > # > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > > # > # Hardware Monitoring support > # > # CONFIG_HWMON is not set > # CONFIG_HWMON_VID is not set > > # > # Misc devices > # > > # > # Multimedia Capabilities Port drivers > # > > # > # Multimedia devices > # > # CONFIG_VIDEO_DEV is not set > > # > # Digital Video Broadcasting Devices > # > > # > # Graphics support > # > # CONFIG_FB is not set > > # > # Console display driver support > # > # CONFIG_VGA_CONSOLE is not set > CONFIG_DUMMY_CONSOLE=y > > # > # Sound > # > # CONFIG_SOUND is not set > > # > # USB support > # > CONFIG_USB_ARCH_HAS_HCD=y > CONFIG_USB_ARCH_HAS_OHCI=y > # CONFIG_USB is not set > > # > # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' > # > > # > # USB Gadget Support > # > # CONFIG_USB_GADGET is not set > > # > # MMC/SD Card support > # > # CONFIG_MMC is not set > > # > # File systems > # > CONFIG_EXT2_FS=y > # CONFIG_EXT2_FS_XATTR is not set > # CONFIG_EXT2_FS_XIP is not set > # CONFIG_EXT3_FS is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > # CONFIG_FS_POSIX_ACL is not set > # CONFIG_XFS_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > # CONFIG_QUOTA is not set > CONFIG_DNOTIFY=y > # CONFIG_AUTOFS_FS is not set > # CONFIG_AUTOFS4_FS is not set > # CONFIG_FUSE_FS is not set > > # > # CD-ROM/DVD Filesystems > # > # CONFIG_ISO9660_FS is not set > # CONFIG_UDF_FS is not set > > # > # DOS/FAT/NT Filesystems > # > # CONFIG_MSDOS_FS is not set > # CONFIG_VFAT_FS is not set > # CONFIG_NTFS_FS is not set > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > CONFIG_SYSFS=y > CONFIG_TMPFS=y > # CONFIG_HUGETLB_PAGE is not set > CONFIG_RAMFS=y > # CONFIG_RELAYFS_FS is not set > # CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > # > # CONFIG_ADFS_FS is not set > # CONFIG_AFFS_FS is not set > # CONFIG_HFS_FS is not set > # CONFIG_HFSPLUS_FS is not set > # CONFIG_BEFS_FS is not set > # CONFIG_BFS_FS is not set > # CONFIG_EFS_FS is not set > CONFIG_CRAMFS=y > # CONFIG_VXFS_FS is not set > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > > # > # Native Language Support > # > # CONFIG_NLS is not set > > # > # Profiling support > # > # CONFIG_PROFILING is not set > > # > # Kernel hacking > # > # CONFIG_PRINTK_TIME is not set > # CONFIG_PRINTK_IGNORE_LOGLEVEL is not set > # CONFIG_MAGIC_SYSRQ is not set > CONFIG_DEBUG_KERNEL=y > CONFIG_LOG_BUF_SHIFT=14 > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > CONFIG_DEBUG_PREEMPT=y > CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_PI_LIST=y > # CONFIG_RT_MUTEX_TESTER is not set > CONFIG_WAKEUP_TIMING=y > # CONFIG_WAKEUP_LATENCY_HIST is not set > CONFIG_PREEMPT_TRACE=y > # CONFIG_CRITICAL_PREEMPT_TIMING is not set > # CONFIG_CRITICAL_IRQSOFF_TIMING is not set > CONFIG_LATENCY_TIMING=y > # CONFIG_LATENCY_TRACE is not set > # CONFIG_DEBUG_KOBJECT is not set > CONFIG_DEBUG_BUGVERBOSE=y > # CONFIG_DEBUG_INFO is not set > # CONFIG_DEBUG_FS is not set > # CONFIG_DEBUG_VM is not set > CONFIG_FORCED_INLINING=y > CONFIG_FRAME_POINTER=y > # CONFIG_RCU_TORTURE_TEST is not set > CONFIG_DEBUG_USER=y > # CONFIG_DEBUG_WAITQ is not set > # CONFIG_DEBUG_ERRORS is not set > CONFIG_DEBUG_LL=y > # CONFIG_DEBUG_ICEDCC is not set > > # > # Security options > # > # CONFIG_KEYS is not set > # CONFIG_SECURITY is not set > > # > # Cryptographic options > # > CONFIG_CRYPTO=y > # CONFIG_CRYPTO_HMAC is not set > # CONFIG_CRYPTO_NULL is not set > # CONFIG_CRYPTO_MD4 is not set > CONFIG_CRYPTO_MD5=y > # CONFIG_CRYPTO_SHA1 is not set > # CONFIG_CRYPTO_SHA256 is not set > # CONFIG_CRYPTO_SHA512 is not set > # CONFIG_CRYPTO_WP512 is not set > # CONFIG_CRYPTO_TGR192 is not set > CONFIG_CRYPTO_DES=y > # CONFIG_CRYPTO_BLOWFISH is not set > # CONFIG_CRYPTO_TWOFISH is not set > # CONFIG_CRYPTO_SERPENT is not set > # CONFIG_CRYPTO_AES is not set > # CONFIG_CRYPTO_CAST5 is not set > # CONFIG_CRYPTO_CAST6 is not set > # CONFIG_CRYPTO_TEA is not set > # CONFIG_CRYPTO_ARC4 is not set > # CONFIG_CRYPTO_KHAZAD is not set > # CONFIG_CRYPTO_ANUBIS is not set > # CONFIG_CRYPTO_DEFLATE is not set > # CONFIG_CRYPTO_MICHAEL_MIC is not set > # CONFIG_CRYPTO_CRC32C is not set > # CONFIG_CRYPTO_TEST is not set > > # > # Hardware crypto devices > # > > # > # Library routines > # > # CONFIG_CRC_CCITT is not set > # CONFIG_CRC16 is not set > CONFIG_CRC32=y > # CONFIG_LIBCRC32C is not set > CONFIG_ZLIB_INFLATE=y > CONFIG_PLIST=y > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Steven Rostedt Senior Programmer Kihon Technologies (607)786-4830 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 13:40 Ingo's realtime_preempt patch causes kernel oops Yann.LEPROVOST 2006-05-23 14:09 ` Steven Rostedt @ 2006-05-23 14:19 ` Steven Rostedt 2006-05-23 14:26 ` Thomas Gleixner 2006-05-23 15:33 ` Daniel Walker 1 sibling, 2 replies; 34+ messages in thread From: Steven Rostedt @ 2006-05-23 14:19 UTC (permalink / raw) To: Yann.LEPROVOST; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar (Resending using my normal email, since my other email doesn't use a registered server) I just CC'd Thomas Gleixner on this, because he does a lot of arm for the -rt patch, as well as included Ingo Molnar since he is the maintainer. On Tue, 2006-05-23 at 15:40 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Hi all, > > I applied last Ingo Molnar's realtime_preempt patch (-rt23) on a vanilla > 2.6.16 kernel. > My architecture is an ARM based CSB637 evaluation board from Cogent. > > I obtain the following kernel oops : > > Uncompressing Linux............................................... done, > booting the kernel. > Linux version 2.6.16-rt23 (yleprovost@wmp-ylplinux) (gcc version 3.4.4) #1 > PREEMPT Tue May 23 15:24:21 CEST 2006 > CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) > Machine: Cogent CSB637 > Warning: bad configuration page, trying to continue > Memory policy: ECC disabled, Data cache writeback > Clocks: CPU 184 MHz, master 46 MHz, main 3.686 MHz > CPU0: D VIVT write-back cache > CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > Real-Time Preemption Support (C) 2004-2006 Ingo Molnar > Built 1 zonelists > Kernel command line: mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 > root=/dev/ram0 rw > WARNING: experimental RCU implementation. > AT91: 128 gpio irqs in 4 banks > PID hash table entries: 256 (order: 8, 4096 bytes) > Console: colour dummy device 80x30 > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Memory: 32MB = 32MB total > Memory: 27828KB available (1100K code, 324K data, 76K init) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > Unable to handle kernel NULL pointer dereference at virtual address > 00000040 > pgd = c0004000 > [00000040] *pgd=00000000 > Internal error: Oops: 5 [#1] > Modules linked in: > CPU: 0 > PC is at profile_tick+0x34/0xa4 > LR is at timer_tick+0x1c/0xe4 > pc : [<c0032724>] lr : [<c001fd34>] Not tainted > sp : c0409f04 ip : c0409f1c fp : c0409f18 > r10: 00000000 r9 : 00000001 r8 : 00000000 > r7 : 00000001 r6 : 00000000 r5 : 00000001 r4 : 00000000 > r3 : 00000000 r2 : 000043ea r1 : 00000000 r0 : 00000000 > Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel > Control: C000717F Table: 20004000 DAC: 00000017 > Process IRQ 1 (pid: 2, stack limit = 0xc0408198) > Stack: (0xc0409f04 to 0xc040a000) > 9f00: 00000000 c016eaf0 c0409f34 c0409f1c c001fd34 c0032700 > fefff000 > 9f20: c016eaf0 00000000 c0409f50 c0409f38 c0025030 c001fd28 c0139a58 > c0408000 > 9f40: 00000000 c0409f80 c0409f54 c0053024 c0024fd4 00000000 00000000 > c01320c0 > 9f60: c0139a58 00000001 fffffffc 00000000 00000000 c0409fa0 c0409f84 > c0053c80 > 9f80: c0052fcc c0132040 c01320c0 c0405edc c0408000 c0409fc4 c0409fa4 > c0053db0 > 9fa0: c0053c30 00000031 c01320c0 c0408000 c0405edc c0053cdc c0409ff4 > c0409fc8 > 9fc0: c00463ac c0053cec 00000001 ffffffff ffffffff 00000000 00000000 > 00000000 > 9fe0: 00000000 00000000 00000000 c0409ff8 c00338e0 c00462cc 6fdb904a > ff3b1884 > Backtrace: > [<c00326f0>] (profile_tick+0x0/0xa4) from [<c001fd34>] > (timer_tick+0x1c/0xe4) > r5 = C016EAF0 r4 = 00000000 > [<c001fd18>] (timer_tick+0x0/0xe4) from [<c0025030>] > (at91rm9200_timer_interrupt+0x6c/0xbc) The above does look arm specific. > r6 = 00000000 r5 = C016EAF0 r4 = FEFFF000 > [<c0024fc4>] (at91rm9200_timer_interrupt+0x0/0xbc) from [<c0053024>] > (handle_IRQ_event+0x68/0xf0) > r6 = 00000000 r5 = C0408000 r4 = C0139A58 > [<c0052fbc>] (handle_IRQ_event+0x0/0xf0) from [<c0053c80>] > (thread_simple_irq+0x60/0xbc) > [<c0053c20>] (thread_simple_irq+0x0/0xbc) from [<c0053db0>] > (do_irqd+0xd4/0x278) > r7 = C0408000 r6 = C0405EDC r5 = C01320C0 r4 = C0132040 > [<c0053cdc>] (do_irqd+0x0/0x278) from [<c00463ac>] (kthread+0xf0/0x120) > r7 = C0053CDC r6 = C0405EDC r5 = C0408000 r4 = C01320C0 > [<c00462bc>] (kthread+0x0/0x120) from [<c00338e0>] (do_exit+0x0/0x8bc) > r8 = 00000000 r7 = 00000000 r6 = 00000000 r5 = 00000000 > r4 = 00000000 > Code: e5933000 e3530000 11a0e00f 11a0f003 (e5943040) > <6>note: IRQ 1[2] exited with preempt_count 1 > BUG: scheduling while atomic: IRQ 1/0x00000001/2 > caller is do_exit+0x838/0x8bc > prev->state: 2 != TASK_RUNNING?? > IRQ 1/2[CPU#0]: BUG in __schedule at kernel/sched.c:3382 > > < ..... Then kernel freezes .....> > > This appears only when CONFIG_PREEMPT_HARDIRQS is enabled. Thomas, The fault is at 0x40 and looking at profile_tick it calls user_mode(regs). user_mode(x) is defined in arm as (((regs)->ARM_cpsr & 0xf) == 0) And ARM_cpsr is uregs[16] So if arm has 4 byte words and regs was NULL, it would fault on 16*4 = 64 or 0x40 It looks like the timer interrupt on this board is having a NULL regs passed to it when hard interrupts are threads. Which might mean that the timer interrupt is itself a thread. -- Steve > The last trace is obtained using CONFIG_RT_PREEMPT which forces > CONFIG_PREEMPT_HARDIRQS to "yes". > For others configurations, when PREEMPT_HARDIRQS is disabled, it works > great. > > It seems to be something dealing with bad irq returns when hardirq > serializing is enabled ?!? > > Has anyone had ever seen this oops before ? > Any clue to solve that ? > > Regards > > Yann Leprovost > > > Here is my current .config file : > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.16-rt23 > # Tue May 23 15:18:53 2006 > # > CONFIG_ARM=y > CONFIG_MMU=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_RWSEM_GENERIC_SPINLOCK=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > > # > # Code maturity level options > # > CONFIG_EXPERIMENTAL=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > > # > # General setup > # > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_IKCONFIG is not set > CONFIG_INITRAMFS_SOURCE="" > CONFIG_UID16=y > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > # CONFIG_EMBEDDED is not set > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_RT_MUTEXES=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > CONFIG_SHMEM=y > CONFIG_CC_ALIGN_FUNCTIONS=0 > CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > CONFIG_SLAB=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > # CONFIG_SLOB is not set > > # > # Loadable module support > # > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODULE_FORCE_UNLOAD is not set > CONFIG_OBSOLETE_MODPARM=y > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > CONFIG_KMOD=y > > # > # Block layer > # > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_AS=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > CONFIG_DEFAULT_AS=y > # CONFIG_DEFAULT_DEADLINE is not set > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="anticipatory" > > # > # System Type > # > # CONFIG_ARCH_CLPS7500 is not set > # CONFIG_ARCH_CLPS711X is not set > # CONFIG_ARCH_CO285 is not set > # CONFIG_ARCH_EBSA110 is not set > # CONFIG_ARCH_FOOTBRIDGE is not set > # CONFIG_ARCH_INTEGRATOR is not set > # CONFIG_ARCH_IOP3XX is not set > # CONFIG_ARCH_IXP4XX is not set > # CONFIG_ARCH_IXP2000 is not set > # CONFIG_ARCH_L7200 is not set > # CONFIG_ARCH_PXA is not set > # CONFIG_ARCH_RPC is not set > # CONFIG_ARCH_SA1100 is not set > # CONFIG_ARCH_S3C2410 is not set > # CONFIG_ARCH_SHARK is not set > # CONFIG_ARCH_LH7A40X is not set > # CONFIG_ARCH_OMAP is not set > # CONFIG_ARCH_VERSATILE is not set > # CONFIG_ARCH_REALVIEW is not set > # CONFIG_ARCH_IMX is not set > # CONFIG_ARCH_H720X is not set > # CONFIG_ARCH_AAEC2000 is not set > CONFIG_ARCH_AT91=y > > # > # Atmel AT91 System-on-Chip > # > CONFIG_ARCH_AT91RM9200=y > > # > # AT91RM9200 Board Type > # > # CONFIG_ARCH_AT91RM9200DK is not set > # CONFIG_MACH_AT91RM9200EK is not set > # CONFIG_MACH_CSB337 is not set > CONFIG_MACH_CSB637=y > # CONFIG_MACH_CARMEVA is not set > # CONFIG_MACH_KB9200 is not set > # CONFIG_MACH_ATEB9200 is not set > # CONFIG_MACH_KAFA is not set > # CONFIG_ARCH_AT91SAM9261 is not set > > # > # AT91 Feature Selections > # > CONFIG_AT91_PROGRAMMABLE_CLOCKS=y > > # > # Processor Type > # > CONFIG_CPU_32=y > CONFIG_CPU_ARM920T=y > CONFIG_CPU_32v4=y > CONFIG_CPU_ABRT_EV4T=y > CONFIG_CPU_CACHE_V4WT=y > CONFIG_CPU_CACHE_VIVT=y > CONFIG_CPU_COPY_V4WB=y > CONFIG_CPU_TLB_V4WBI=y > > # > # Processor Features > # > # CONFIG_ARM_THUMB is not set > # CONFIG_CPU_ICACHE_DISABLE is not set > # CONFIG_CPU_DCACHE_DISABLE is not set > # CONFIG_CPU_DCACHE_WRITETHROUGH is not set > > # > # Bus support > # > > # > # PCCARD (PCMCIA/CardBus) support > # > CONFIG_PCCARD=y > # CONFIG_PCMCIA_DEBUG is not set > CONFIG_PCMCIA=y > CONFIG_PCMCIA_LOAD_CIS=y > CONFIG_PCMCIA_IOCTL=y > > # > # PC-card bridges > # > CONFIG_AT91_CF=y > > # > # Kernel Features > # > # CONFIG_PREEMPT_NONE is not set > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT_DESKTOP is not set > CONFIG_PREEMPT_RT=y > CONFIG_PREEMPT=y > CONFIG_PREEMPT_SOFTIRQS=y > CONFIG_PREEMPT_HARDIRQS=y > CONFIG_PREEMPT_BKL=y > # CONFIG_CLASSIC_RCU is not set > CONFIG_PREEMPT_RCU=y > CONFIG_RCU_STATS=y > # CONFIG_NO_IDLE_HZ is not set > # CONFIG_AEABI is not set > # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_MANUAL=y > # CONFIG_DISCONTIGMEM_MANUAL is not set > # CONFIG_SPARSEMEM_MANUAL is not set > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > # CONFIG_SPARSEMEM_STATIC is not set > CONFIG_SPLIT_PTLOCK_CPUS=4096 > # CONFIG_LEDS is not set > CONFIG_ALIGNMENT_TRAP=y > > # > # Boot options > # > CONFIG_ZBOOT_ROM_TEXT=0x0 > CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_CMDLINE="mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 > root=/dev/ram0 rw" > # CONFIG_XIP_KERNEL is not set > > # > # Floating point emulation > # > > # > # At least one emulation must be selected > # > CONFIG_FPE_NWFPE=y > # CONFIG_FPE_NWFPE_XP is not set > # CONFIG_FPE_FASTFPE is not set > > # > # Userspace binary formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > # CONFIG_ARTHUR is not set > > # > # Power management options > # > # CONFIG_PM is not set > # CONFIG_APM is not set > > # > # Networking > # > # CONFIG_NET is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > CONFIG_STANDALONE=y > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FW_LOADER=y > # CONFIG_DEBUG_DRIVER is not set > > # > # Connector - unified userspace <-> kernelspace linker > # > > # > # Memory Technology Devices (MTD) > # > # CONFIG_MTD is not set > > # > # Parallel port support > # > # CONFIG_PARPORT is not set > > # > # Plug and Play support > # > > # > # Block devices > # > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=y > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=16 > CONFIG_BLK_DEV_RAM_SIZE=8192 > CONFIG_BLK_DEV_INITRD=y > # CONFIG_CDROM_PKTCDVD is not set > > # > # ATA/ATAPI/MFM/RLL support > # > # CONFIG_IDE is not set > > # > # SCSI device support > # > # CONFIG_RAID_ATTRS is not set > CONFIG_SCSI=y > # CONFIG_SCSI_PROC_FS is not set > > # > # SCSI support type (disk, tape, CD-ROM) > # > # CONFIG_BLK_DEV_SD is not set > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > # CONFIG_BLK_DEV_SR is not set > # CONFIG_CHR_DEV_SG is not set > # CONFIG_CHR_DEV_SCH is not set > > # > # Some SCSI devices (e.g. CD jukebox) support multiple LUNs > # > # CONFIG_SCSI_MULTI_LUN is not set > # CONFIG_SCSI_CONSTANTS is not set > # CONFIG_SCSI_LOGGING is not set > > # > # SCSI Transport Attributes > # > # CONFIG_SCSI_SPI_ATTRS is not set > # CONFIG_SCSI_FC_ATTRS is not set > # CONFIG_SCSI_SAS_ATTRS is not set > > # > # SCSI low-level drivers > # > # CONFIG_SCSI_SATA is not set > # CONFIG_SCSI_DEBUG is not set > > # > # PCMCIA SCSI adapter support > # > # CONFIG_PCMCIA_AHA152X is not set > # CONFIG_PCMCIA_FDOMAIN is not set > # CONFIG_PCMCIA_NINJA_SCSI is not set > # CONFIG_PCMCIA_QLOGIC is not set > # CONFIG_PCMCIA_SYM53C500 is not set > > # > # Multi-device support (RAID and LVM) > # > # CONFIG_MD is not set > > # > # Fusion MPT device support > # > # CONFIG_FUSION is not set > > # > # IEEE 1394 (FireWire) support > # > > # > # I2O device support > # > > # > # ISDN subsystem > # > > # > # Input device support > # > CONFIG_INPUT=y > > # > # Userland interfaces > # > CONFIG_INPUT_MOUSEDEV=y > # CONFIG_INPUT_MOUSEDEV_PSAUX is not set > CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_TSDEV is not set > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input Device Drivers > # > # CONFIG_INPUT_KEYBOARD is not set > # CONFIG_INPUT_MOUSE is not set > # CONFIG_INPUT_JOYSTICK is not set > # CONFIG_INPUT_TOUCHSCREEN is not set > # CONFIG_INPUT_MISC is not set > > # > # Hardware I/O ports > # > # CONFIG_SERIO is not set > # CONFIG_GAMEPORT is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_HW_CONSOLE=y > # CONFIG_SERIAL_NONSTANDARD is not set > > # > # Serial drivers > # > # CONFIG_SERIAL_8250 is not set > > # > # Non-8250 serial port support > # > CONFIG_SERIAL_AT91=y > CONFIG_SERIAL_AT91_CONSOLE=y > # CONFIG_SERIAL_AT91_TTYAT is not set > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > CONFIG_UNIX98_PTYS=y > CONFIG_LEGACY_PTYS=y > CONFIG_LEGACY_PTY_COUNT=256 > > # > # IPMI > # > # CONFIG_IPMI_HANDLER is not set > > # > # Watchdog Cards > # > CONFIG_WATCHDOG=y > CONFIG_WATCHDOG_NOWAYOUT=y > > # > # Watchdog Device Drivers > # > # CONFIG_SOFT_WATCHDOG is not set > CONFIG_AT91_WATCHDOG=y > # CONFIG_NVRAM is not set > CONFIG_RTC=y > # CONFIG_RTC_HISTOGRAM is not set > # CONFIG_AT91_RTC is not set > # CONFIG_DTLK is not set > # CONFIG_R3964 is not set > > # > # Ftape, the floppy tape device driver > # > > # > # PCMCIA character devices > # > # CONFIG_SYNCLINK_CS is not set > # CONFIG_CARDMAN_4000 is not set > # CONFIG_CARDMAN_4040 is not set > # CONFIG_RAW_DRIVER is not set > > # > # TPM devices > # > # CONFIG_TCG_TPM is not set > # CONFIG_TELCLOCK is not set > CONFIG_AT91_SPI=y > CONFIG_AT91_SPIDEV=y > > # > # I2C support > # > # CONFIG_I2C is not set > > # > # SPI support > # > # CONFIG_SPI is not set > # CONFIG_SPI_MASTER is not set > > # > # Dallas's 1-wire bus > # > # CONFIG_W1 is not set > > # > # Hardware Monitoring support > # > # CONFIG_HWMON is not set > # CONFIG_HWMON_VID is not set > > # > # Misc devices > # > > # > # Multimedia Capabilities Port drivers > # > > # > # Multimedia devices > # > # CONFIG_VIDEO_DEV is not set > > # > # Digital Video Broadcasting Devices > # > > # > # Graphics support > # > # CONFIG_FB is not set > > # > # Console display driver support > # > # CONFIG_VGA_CONSOLE is not set > CONFIG_DUMMY_CONSOLE=y > > # > # Sound > # > # CONFIG_SOUND is not set > > # > # USB support > # > CONFIG_USB_ARCH_HAS_HCD=y > CONFIG_USB_ARCH_HAS_OHCI=y > # CONFIG_USB is not set > > # > # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' > # > > # > # USB Gadget Support > # > # CONFIG_USB_GADGET is not set > > # > # MMC/SD Card support > # > # CONFIG_MMC is not set > > # > # File systems > # > CONFIG_EXT2_FS=y > # CONFIG_EXT2_FS_XATTR is not set > # CONFIG_EXT2_FS_XIP is not set > # CONFIG_EXT3_FS is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > # CONFIG_FS_POSIX_ACL is not set > # CONFIG_XFS_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > # CONFIG_QUOTA is not set > CONFIG_DNOTIFY=y > # CONFIG_AUTOFS_FS is not set > # CONFIG_AUTOFS4_FS is not set > # CONFIG_FUSE_FS is not set > > # > # CD-ROM/DVD Filesystems > # > # CONFIG_ISO9660_FS is not set > # CONFIG_UDF_FS is not set > > # > # DOS/FAT/NT Filesystems > # > # CONFIG_MSDOS_FS is not set > # CONFIG_VFAT_FS is not set > # CONFIG_NTFS_FS is not set > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > CONFIG_SYSFS=y > CONFIG_TMPFS=y > # CONFIG_HUGETLB_PAGE is not set > CONFIG_RAMFS=y > # CONFIG_RELAYFS_FS is not set > # CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > # > # CONFIG_ADFS_FS is not set > # CONFIG_AFFS_FS is not set > # CONFIG_HFS_FS is not set > # CONFIG_HFSPLUS_FS is not set > # CONFIG_BEFS_FS is not set > # CONFIG_BFS_FS is not set > # CONFIG_EFS_FS is not set > CONFIG_CRAMFS=y > # CONFIG_VXFS_FS is not set > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > > # > # Native Language Support > # > # CONFIG_NLS is not set > > # > # Profiling support > # > # CONFIG_PROFILING is not set > > # > # Kernel hacking > # > # CONFIG_PRINTK_TIME is not set > # CONFIG_PRINTK_IGNORE_LOGLEVEL is not set > # CONFIG_MAGIC_SYSRQ is not set > CONFIG_DEBUG_KERNEL=y > CONFIG_LOG_BUF_SHIFT=14 > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > CONFIG_DEBUG_PREEMPT=y > CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_PI_LIST=y > # CONFIG_RT_MUTEX_TESTER is not set > CONFIG_WAKEUP_TIMING=y > # CONFIG_WAKEUP_LATENCY_HIST is not set > CONFIG_PREEMPT_TRACE=y > # CONFIG_CRITICAL_PREEMPT_TIMING is not set > # CONFIG_CRITICAL_IRQSOFF_TIMING is not set > CONFIG_LATENCY_TIMING=y > # CONFIG_LATENCY_TRACE is not set > # CONFIG_DEBUG_KOBJECT is not set > CONFIG_DEBUG_BUGVERBOSE=y > # CONFIG_DEBUG_INFO is not set > # CONFIG_DEBUG_FS is not set > # CONFIG_DEBUG_VM is not set > CONFIG_FORCED_INLINING=y > CONFIG_FRAME_POINTER=y > # CONFIG_RCU_TORTURE_TEST is not set > CONFIG_DEBUG_USER=y > # CONFIG_DEBUG_WAITQ is not set > # CONFIG_DEBUG_ERRORS is not set > CONFIG_DEBUG_LL=y > # CONFIG_DEBUG_ICEDCC is not set > > # > # Security options > # > # CONFIG_KEYS is not set > # CONFIG_SECURITY is not set > > # > # Cryptographic options > # > CONFIG_CRYPTO=y > # CONFIG_CRYPTO_HMAC is not set > # CONFIG_CRYPTO_NULL is not set > # CONFIG_CRYPTO_MD4 is not set > CONFIG_CRYPTO_MD5=y > # CONFIG_CRYPTO_SHA1 is not set > # CONFIG_CRYPTO_SHA256 is not set > # CONFIG_CRYPTO_SHA512 is not set > # CONFIG_CRYPTO_WP512 is not set > # CONFIG_CRYPTO_TGR192 is not set > CONFIG_CRYPTO_DES=y > # CONFIG_CRYPTO_BLOWFISH is not set > # CONFIG_CRYPTO_TWOFISH is not set > # CONFIG_CRYPTO_SERPENT is not set > # CONFIG_CRYPTO_AES is not set > # CONFIG_CRYPTO_CAST5 is not set > # CONFIG_CRYPTO_CAST6 is not set > # CONFIG_CRYPTO_TEA is not set > # CONFIG_CRYPTO_ARC4 is not set > # CONFIG_CRYPTO_KHAZAD is not set > # CONFIG_CRYPTO_ANUBIS is not set > # CONFIG_CRYPTO_DEFLATE is not set > # CONFIG_CRYPTO_MICHAEL_MIC is not set > # CONFIG_CRYPTO_CRC32C is not set > # CONFIG_CRYPTO_TEST is not set > > # > # Hardware crypto devices > # > > # > # Library routines > # > # CONFIG_CRC_CCITT is not set > # CONFIG_CRC16 is not set > CONFIG_CRC32=y > # CONFIG_LIBCRC32C is not set > CONFIG_ZLIB_INFLATE=y > CONFIG_PLIST=y > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 14:19 ` Steven Rostedt @ 2006-05-23 14:26 ` Thomas Gleixner 2006-05-23 15:33 ` Daniel Walker 1 sibling, 0 replies; 34+ messages in thread From: Thomas Gleixner @ 2006-05-23 14:26 UTC (permalink / raw) To: Steven Rostedt; +Cc: Yann.LEPROVOST, linux-kernel, Ingo Molnar On Tue, 2006-05-23 at 10:19 -0400, Steven Rostedt wrote: > It looks like the timer interrupt on this board is having a NULL regs > passed to it when hard interrupts are threads. Which might mean that > the timer interrupt is itself a thread. Yes, the timer interrupt must be setup with SA_INTERUPT | SA_NODELAY set. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 14:19 ` Steven Rostedt 2006-05-23 14:26 ` Thomas Gleixner @ 2006-05-23 15:33 ` Daniel Walker 2006-05-23 16:02 ` Steven Rostedt 1 sibling, 1 reply; 34+ messages in thread From: Daniel Walker @ 2006-05-23 15:33 UTC (permalink / raw) To: Steven Rostedt; +Cc: Yann.LEPROVOST, linux-kernel, Thomas Gleixner, Ingo Molnar On Tue, 2006-05-23 at 10:19 -0400, Steven Rostedt wrote: > > The fault is at 0x40 and looking at profile_tick it calls > user_mode(regs). user_mode(x) is defined in arm as > (((regs)->ARM_cpsr & 0xf) == 0) > > And ARM_cpsr is uregs[16] So if arm has 4 byte words and regs was NULL, > it would fault on 16*4 = 64 or 0x40 > > It looks like the timer interrupt on this board is having a NULL regs > passed to it when hard interrupts are threads. Which might mean that > the timer interrupt is itself a thread. Hmm, well usually ARM timer interrupts have the SA_TIMER flag .. In realtime ARM changes SA_TIMER includes SA_NODELAY .. In 2.6.17-rc4 arch/arm/mach-at91rm9200/time.c static struct irqaction at91rm9200_timer_irq = { .name = "at91_tick", .flags = SA_SHIRQ | SA_INTERRUPT, .handler = at91rm9200_timer_interrupt }; No SA_TIMER, and no SA_NODELAY , so i'd imagine it's is in a thread .. Daniel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 15:33 ` Daniel Walker @ 2006-05-23 16:02 ` Steven Rostedt 2006-05-23 16:27 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Steven Rostedt @ 2006-05-23 16:02 UTC (permalink / raw) To: Daniel Walker; +Cc: Yann.LEPROVOST, linux-kernel, Thomas Gleixner, Ingo Molnar On Tue, 2006-05-23 at 08:33 -0700, Daniel Walker wrote: > On Tue, 2006-05-23 at 10:19 -0400, Steven Rostedt wrote: > > > > > The fault is at 0x40 and looking at profile_tick it calls > > user_mode(regs). user_mode(x) is defined in arm as > > (((regs)->ARM_cpsr & 0xf) == 0) > > > > And ARM_cpsr is uregs[16] So if arm has 4 byte words and regs was NULL, > > it would fault on 16*4 = 64 or 0x40 > > > > It looks like the timer interrupt on this board is having a NULL regs > > passed to it when hard interrupts are threads. Which might mean that > > the timer interrupt is itself a thread. > > Hmm, well usually ARM timer interrupts have the SA_TIMER flag .. In > realtime ARM changes SA_TIMER includes SA_NODELAY .. > > In 2.6.17-rc4 > > arch/arm/mach-at91rm9200/time.c > > static struct irqaction at91rm9200_timer_irq = { > .name = "at91_tick", > .flags = SA_SHIRQ | SA_INTERRUPT, > .handler = at91rm9200_timer_interrupt > }; > > No SA_TIMER, and no SA_NODELAY , so i'd imagine it's is in a thread .. Yep, I would say it is. Yann, could you try the following patch to see if it makes it better for you. I added SA_NODELAY so that the timer is run in interrupt context, and removed the shared flag, because I have no idea what might share a timer interrupt, and it might cause other bugs. If something needs to share this interrupt, then we need to do something else. Since I don't have any arm boards, I cant test it, so this wasn't even compiled. -- Steve Index: linux-2.6.16-rt23/arch/arm/mach-at91rm9200/time.c =================================================================== --- linux-2.6.16-rt23.orig/arch/arm/mach-at91rm9200/time.c 2006-05-23 11:58:21.000000000 -0400 +++ linux-2.6.16-rt23/arch/arm/mach-at91rm9200/time.c 2006-05-23 11:58:45.000000000 -0400 @@ -87,7 +87,7 @@ static irqreturn_t at91rm9200_timer_inte static struct irqaction at91rm9200_timer_irq = { .name = "at91_tick", - .flags = SA_SHIRQ | SA_INTERRUPT, + .flags = SA_INTERRUPT | SA_NODELAY, .handler = at91rm9200_timer_interrupt }; ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 16:02 ` Steven Rostedt @ 2006-05-23 16:27 ` Yann.LEPROVOST 2006-05-23 17:00 ` Steven Rostedt 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-23 16:27 UTC (permalink / raw) To: Steven Rostedt; +Cc: Daniel Walker, linux-kernel, Ingo Molnar, Thomas Gleixner I forgot to say that I let SA_SHIRQ as the IRQ line is shared... It seems to work correctly... Yann Steven Rostedt <rostedt@goodmis. org> To Daniel Walker <dwalker@mvista.com> 23/05/2006 18:02 cc Yann.LEPROVOST@wavecom.fr, linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu> Subject Re: Ingo's realtime_preempt patch causes kernel oops On Tue, 2006-05-23 at 08:33 -0700, Daniel Walker wrote: > On Tue, 2006-05-23 at 10:19 -0400, Steven Rostedt wrote: > > > > > The fault is at 0x40 and looking at profile_tick it calls > > user_mode(regs). user_mode(x) is defined in arm as > > (((regs)->ARM_cpsr & 0xf) == 0) > > > > And ARM_cpsr is uregs[16] So if arm has 4 byte words and regs was NULL, > > it would fault on 16*4 = 64 or 0x40 > > > > It looks like the timer interrupt on this board is having a NULL regs > > passed to it when hard interrupts are threads. Which might mean that > > the timer interrupt is itself a thread. > > Hmm, well usually ARM timer interrupts have the SA_TIMER flag .. In > realtime ARM changes SA_TIMER includes SA_NODELAY .. > > In 2.6.17-rc4 > > arch/arm/mach-at91rm9200/time.c > > static struct irqaction at91rm9200_timer_irq = { > .name = "at91_tick", > .flags = SA_SHIRQ | SA_INTERRUPT, > .handler = at91rm9200_timer_interrupt > }; > > No SA_TIMER, and no SA_NODELAY , so i'd imagine it's is in a thread .. Yep, I would say it is. Yann, could you try the following patch to see if it makes it better for you. I added SA_NODELAY so that the timer is run in interrupt context, and removed the shared flag, because I have no idea what might share a timer interrupt, and it might cause other bugs. If something needs to share this interrupt, then we need to do something else. Since I don't have any arm boards, I cant test it, so this wasn't even compiled. -- Steve Index: linux-2.6.16-rt23/arch/arm/mach-at91rm9200/time.c =================================================================== --- linux-2.6.16-rt23.orig/arch/arm/mach-at91rm9200/time.c 2006-05-23 11:58:21.000000000 -0400 +++ linux-2.6.16-rt23/arch/arm/mach-at91rm9200/time.c 2006-05-23 11:58:45.000000000 -0400 @@ -87,7 +87,7 @@ static irqreturn_t at91rm9200_timer_inte static struct irqaction at91rm9200_timer_irq = { .name = "at91_tick", - .flags = SA_SHIRQ | SA_INTERRUPT, + .flags = SA_INTERRUPT | SA_NODELAY, .handler = at91rm9200_timer_interrupt }; ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 16:27 ` Yann.LEPROVOST @ 2006-05-23 17:00 ` Steven Rostedt 2006-05-23 17:10 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Steven Rostedt @ 2006-05-23 17:00 UTC (permalink / raw) To: Yann.LEPROVOST; +Cc: Daniel Walker, linux-kernel, Ingo Molnar, Thomas Gleixner On Tue, 2006-05-23 at 18:27 +0200, Yann.LEPROVOST@wavecom.fr wrote: > I forgot to say that I let SA_SHIRQ as the IRQ line is shared... > It seems to work correctly... What shares it? Reason I ask, is that this irq is now running in true interrupt context, and that on PREEMPT_RT the spin_locks are mutexes and can schedule. So if another device is sharing this irq, then its interrupt handler will be running in interrupt context, and if it grabs a spin_lock than is not a raw_spinlock_t then you will have a crash. This won't be a problem if you only turn on Hard irqs as threads and don't do the PREEMPT_RT. -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 17:00 ` Steven Rostedt @ 2006-05-23 17:10 ` Yann.LEPROVOST 2006-05-23 18:21 ` Steven Rostedt 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-23 17:10 UTC (permalink / raw) To: Steven Rostedt Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner Currently there are only system timer and debug serial unit registered on irq line 1. Debug serial unit is used as the console ! Steven Rostedt <rostedt@goodmis. org> To Sent by: Yann.LEPROVOST@wavecom.fr linux-kernel-owne cc r@vger.kernel.org Daniel Walker <dwalker@mvista.com>, linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>, Thomas 23/05/2006 19:00 Gleixner <tglx@linutronix.de> Subject Re: Ingo's realtime_preempt patch causes kernel oops On Tue, 2006-05-23 at 18:27 +0200, Yann.LEPROVOST@wavecom.fr wrote: > I forgot to say that I let SA_SHIRQ as the IRQ line is shared... > It seems to work correctly... What shares it? Reason I ask, is that this irq is now running in true interrupt context, and that on PREEMPT_RT the spin_locks are mutexes and can schedule. So if another device is sharing this irq, then its interrupt handler will be running in interrupt context, and if it grabs a spin_lock than is not a raw_spinlock_t then you will have a crash. This won't be a problem if you only turn on Hard irqs as threads and don't do the PREEMPT_RT. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 17:10 ` Yann.LEPROVOST @ 2006-05-23 18:21 ` Steven Rostedt 2006-05-24 8:06 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Steven Rostedt @ 2006-05-23 18:21 UTC (permalink / raw) To: Yann.LEPROVOST Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner On Tue, 2006-05-23 at 19:10 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Currently there are only system timer and debug serial unit registered on > irq line 1. > Debug serial unit is used as the console ! > That scares me. Is the debug serial unit added by you, or is it part of the mainline kernel? -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 18:21 ` Steven Rostedt @ 2006-05-24 8:06 ` Yann.LEPROVOST 2006-05-24 12:55 ` Steven Rostedt 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-24 8:06 UTC (permalink / raw) To: Steven Rostedt Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner The debug serial unit is part of the mainline kernel, this is the common link to work with the CSB637 Cogent board. I don't know about others AT91RM9200 based board. AT91RM9200 also have others USART, but there are no available output connectors on the CSB637 board. Yann Steven Rostedt <rostedt@goodmis. org> To Yann.LEPROVOST@wavecom.fr 23/05/2006 20:21 cc Daniel Walker <dwalker@mvista.com>, linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org, Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de> Subject Re: Ingo's realtime_preempt patch causes kernel oops On Tue, 2006-05-23 at 19:10 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Currently there are only system timer and debug serial unit registered on > irq line 1. > Debug serial unit is used as the console ! > That scares me. Is the debug serial unit added by you, or is it part of the mainline kernel? -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 8:06 ` Yann.LEPROVOST @ 2006-05-24 12:55 ` Steven Rostedt 2006-05-24 13:13 ` Thomas Gleixner ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Steven Rostedt @ 2006-05-24 12:55 UTC (permalink / raw) To: Yann.LEPROVOST Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@wavecom.fr wrote: > The debug serial unit is part of the mainline kernel, this is the common > link to work with the CSB637 Cogent board. > I don't know about others AT91RM9200 based board. > > AT91RM9200 also have others USART, but there are no available output > connectors on the CSB637 board. > Hi Yann, OK, do you only get the prints from the serial? If so than that is OK, but if you also log in through the serial, then that is a problem. In other words, do you have something like mgetty running to log in through the serial? Looking at the at91_interrupt it can call mutex spin_locks if receiving data. So this needs care. Thomas or Ingo, Maybe the handling of IRQs needs to handle the case that shared irq can have both a NODELAY and a thread. The irq descriptor could have a NODELAY set if any of the actions are NODELAY, but before calling the interrupt handler (in interrupt context), check if the action is NODELAY or not, and if not, wake up the thread if not done so already. thoughts? -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 12:55 ` Steven Rostedt @ 2006-05-24 13:13 ` Thomas Gleixner 2006-05-24 15:32 ` Sven-Thorsten Dietrich 2006-05-24 13:58 ` Yann.LEPROVOST 2006-05-24 16:43 ` Esben Nielsen 2 siblings, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-24 13:13 UTC (permalink / raw) To: Steven Rostedt Cc: Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 08:55 -0400, Steven Rostedt wrote: > Thomas or Ingo, > > Maybe the handling of IRQs needs to handle the case that shared irq can > have both a NODELAY and a thread. The irq descriptor could have a > NODELAY set if any of the actions are NODELAY, but before calling the > interrupt handler (in interrupt context), check if the action is NODELAY > or not, and if not, wake up the thread if not done so already. As I said yesterday. You need a demultiplexer for such cases. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 13:13 ` Thomas Gleixner @ 2006-05-24 15:32 ` Sven-Thorsten Dietrich 2006-05-24 15:52 ` Steven Rostedt 0 siblings, 1 reply; 34+ messages in thread From: Sven-Thorsten Dietrich @ 2006-05-24 15:32 UTC (permalink / raw) To: tglx Cc: Steven Rostedt, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 15:13 +0200, Thomas Gleixner wrote: > On Wed, 2006-05-24 at 08:55 -0400, Steven Rostedt wrote: > > Thomas or Ingo, > > > > Maybe the handling of IRQs needs to handle the case that shared irq can > > have both a NODELAY and a thread. The irq descriptor could have a > > NODELAY set if any of the actions are NODELAY, but before calling the > > interrupt handler (in interrupt context), check if the action is NODELAY > > or not, and if not, wake up the thread if not done so already. > > As I said yesterday. You need a demultiplexer for such cases. > Would IRQs stay masked until the thread has finished running? Sven ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 15:32 ` Sven-Thorsten Dietrich @ 2006-05-24 15:52 ` Steven Rostedt 2006-05-24 16:03 ` Thomas Gleixner 2006-05-24 16:06 ` Daniel Walker 0 siblings, 2 replies; 34+ messages in thread From: Steven Rostedt @ 2006-05-24 15:52 UTC (permalink / raw) To: Sven-Thorsten Dietrich Cc: tglx, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 08:32 -0700, Sven-Thorsten Dietrich wrote: > On Wed, 2006-05-24 at 15:13 +0200, Thomas Gleixner wrote: > > On Wed, 2006-05-24 at 08:55 -0400, Steven Rostedt wrote: > > > Thomas or Ingo, > > > > > > Maybe the handling of IRQs needs to handle the case that shared irq can > > > have both a NODELAY and a thread. The irq descriptor could have a > > > NODELAY set if any of the actions are NODELAY, but before calling the > > > interrupt handler (in interrupt context), check if the action is NODELAY > > > or not, and if not, wake up the thread if not done so already. > > > > As I said yesterday. You need a demultiplexer for such cases. > > > > Would IRQs stay masked until the thread has finished running? I would say yes. But the system is basically broken if you have the same interrupt line that needs both to be threaded and NODELAY. Basically, the best I can think to have for such a case, is all interrupt threads that have a shared NODELAY run at MAX_PRIO (99). So that they act like a NODELAY interrupt, in that they run over everything else, but they can still schedule. -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 15:52 ` Steven Rostedt @ 2006-05-24 16:03 ` Thomas Gleixner 2006-05-24 16:38 ` Steven Rostedt 2006-05-24 16:06 ` Daniel Walker 1 sibling, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-24 16:03 UTC (permalink / raw) To: Steven Rostedt Cc: Sven-Thorsten Dietrich, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 11:52 -0400, Steven Rostedt wrote: > > > As I said yesterday. You need a demultiplexer for such cases. > > > > > > > Would IRQs stay masked until the thread has finished running? > > I would say yes. But the system is basically broken if you have the > same interrupt line that needs both to be threaded and NODELAY. > > Basically, the best I can think to have for such a case, is all > interrupt threads that have a shared NODELAY run at MAX_PRIO (99). So > that they act like a NODELAY interrupt, in that they run over everything > else, but they can still schedule. Err. That's why you use demultiplexers. The demux handler is always NODELAY. shared IRQ -> demux_handler disable shared irq identify interrupt sources for all sources: calculate the interrupt number irq_desc[number]->handle_irq(.....) disable/ack a particular source if NODELAY call handler and reenable if appropriate else wakeup thread enable shared irq That's the way you really want to do it. Granted, that this is not possible with the current implementation of PCI cards, but for the SoC peripherals this is usually simple to do. The ARM tree has tons of examples which do exactly this. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 16:03 ` Thomas Gleixner @ 2006-05-24 16:38 ` Steven Rostedt 2006-05-24 16:55 ` Thomas Gleixner 0 siblings, 1 reply; 34+ messages in thread From: Steven Rostedt @ 2006-05-24 16:38 UTC (permalink / raw) To: tglx Cc: Sven-Thorsten Dietrich, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 18:03 +0200, Thomas Gleixner wrote: > On Wed, 2006-05-24 at 11:52 -0400, Steven Rostedt wrote: > > > > As I said yesterday. You need a demultiplexer for such cases. > > > > > > > > > > Would IRQs stay masked until the thread has finished running? > > > > I would say yes. But the system is basically broken if you have the > > same interrupt line that needs both to be threaded and NODELAY. > > > > Basically, the best I can think to have for such a case, is all > > interrupt threads that have a shared NODELAY run at MAX_PRIO (99). So > > that they act like a NODELAY interrupt, in that they run over everything > > else, but they can still schedule. > > Err. That's why you use demultiplexers. The demux handler is always > NODELAY. > > shared IRQ > -> demux_handler > disable shared irq > identify interrupt sources > for all sources: > calculate the interrupt number > irq_desc[number]->handle_irq(.....) > disable/ack a particular source > if NODELAY > call handler and reenable if appropriate > else > wakeup thread > enable shared irq > > That's the way you really want to do it. Granted, that this is not > possible with the current implementation of PCI cards, but for the SoC > peripherals this is usually simple to do. > > The ARM tree has tons of examples which do exactly this. > OK I haven't worked on arm much at all. Only had to port one board before, and didn't need to get too involved. Can't two devices share the same interrupt line? Not talking about a cascading interrupt controller, but two actual devices that can trigger a single interrupt line. So, if this is the case, how do you disable a particular source without going to the driver itself? If this is not the case, and the interrupt line that is shared has another controller that the devices are separated on, then this is trivial. But I don't know the setup in question. -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 16:38 ` Steven Rostedt @ 2006-05-24 16:55 ` Thomas Gleixner 2006-05-24 17:09 ` Sven-Thorsten Dietrich 0 siblings, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-24 16:55 UTC (permalink / raw) To: Steven Rostedt Cc: Sven-Thorsten Dietrich, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 12:38 -0400, Steven Rostedt wrote: > OK I haven't worked on arm much at all. Only had to port one board > before, and didn't need to get too involved. > > Can't two devices share the same interrupt line? Not talking about a > cascading interrupt controller, but two actual devices that can trigger > a single interrupt line. So, if this is the case, how do you disable a > particular source without going to the driver itself? Yeah, the demux code has to go into the device driver to figure that out, which is not hard to do on SoC devices, as the peripherals are usually unique for a given SoC family. PCI and other globally shared devices are completely differnt beasts and you would need a legion of hackers to fix that up. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 16:55 ` Thomas Gleixner @ 2006-05-24 17:09 ` Sven-Thorsten Dietrich 0 siblings, 0 replies; 34+ messages in thread From: Sven-Thorsten Dietrich @ 2006-05-24 17:09 UTC (permalink / raw) To: tglx Cc: Steven Rostedt, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar On Wed, 2006-05-24 at 18:55 +0200, Thomas Gleixner wrote: > On Wed, 2006-05-24 at 12:38 -0400, Steven Rostedt wrote: > > OK I haven't worked on arm much at all. Only had to port one board > > before, and didn't need to get too involved. > > > > Can't two devices share the same interrupt line? Not talking about a > > cascading interrupt controller, but two actual devices that can trigger > > a single interrupt line. So, if this is the case, how do you disable a > > particular source without going to the driver itself? > > Yeah, the demux code has to go into the device driver to figure that > out, which is not hard to do on SoC devices, as the peripherals are > usually unique for a given SoC family. > > PCI and other globally shared devices are completely differnt beasts and > you would need a legion of hackers to fix that up. > I am looking at a particular case where I am dealing with it on PCI, and sharing USB. In this particular case, the uhci USB driver is almost structured, such that we can execute the lockless portion, and then run the locked code in a thread... Sven > tglx > > -- *********************************** Sven-Thorsten Dietrich Real-Time Software Architect MontaVista Software, Inc. 2901 Patrick Henry Drive, Suite 150 Santa Clara, CA 95054-1831 Direct: 408.572.7870 Main: 408.572.8000 Fax: 408.572.8005 www.mvista.com Platform To Innovate *********************************** ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 15:52 ` Steven Rostedt 2006-05-24 16:03 ` Thomas Gleixner @ 2006-05-24 16:06 ` Daniel Walker 1 sibling, 0 replies; 34+ messages in thread From: Daniel Walker @ 2006-05-24 16:06 UTC (permalink / raw) To: Steven Rostedt Cc: Sven-Thorsten Dietrich, tglx, Yann.LEPROVOST, linux-kernel, linux-kernel-owner, Ingo Molnar > Would IRQs stay masked until the thread has finished running? > > I would say yes. But the system is basically broken if you have the > same interrupt line that needs both to be threaded and NODELAY. It's certainly less than and ideal situation .. If set an interrupt as SA_NODELAY you'd think that it's suppose to be high priority , but then you share it with something that's not high high priority which doesn't make a lot of sense .. However, the PCI bus doesn't (as far as I know) allow for interrupts to easily be isolated .. So, with PCI, you may end up with potentially high priority interrupts shared with some other interrupt .. So it is a situation that could happen, maybe even often . Daniel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 12:55 ` Steven Rostedt 2006-05-24 13:13 ` Thomas Gleixner @ 2006-05-24 13:58 ` Yann.LEPROVOST 2006-05-24 16:43 ` Esben Nielsen 2 siblings, 0 replies; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-24 13:58 UTC (permalink / raw) To: Steven Rostedt Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner Yeah, I'm using minicom to log in through the serial debug unit, meaning that there are probably many incoming intterrupts corresponding to input characters... Yann Steven Rostedt <rostedt@goodmis. org> To Yann.LEPROVOST@wavecom.fr 24/05/2006 14:55 cc Daniel Walker <dwalker@mvista.com>, linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org, Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de> Subject Re: Ingo's realtime_preempt patch causes kernel oops On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@wavecom.fr wrote: > The debug serial unit is part of the mainline kernel, this is the common > link to work with the CSB637 Cogent board. > I don't know about others AT91RM9200 based board. > > AT91RM9200 also have others USART, but there are no available output > connectors on the CSB637 board. > Hi Yann, OK, do you only get the prints from the serial? If so than that is OK, but if you also log in through the serial, then that is a problem. In other words, do you have something like mgetty running to log in through the serial? Looking at the at91_interrupt it can call mutex spin_locks if receiving data. So this needs care. Thomas or Ingo, Maybe the handling of IRQs needs to handle the case that shared irq can have both a NODELAY and a thread. The irq descriptor could have a NODELAY set if any of the actions are NODELAY, but before calling the interrupt handler (in interrupt context), check if the action is NODELAY or not, and if not, wake up the thread if not done so already. thoughts? -- Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 12:55 ` Steven Rostedt 2006-05-24 13:13 ` Thomas Gleixner 2006-05-24 13:58 ` Yann.LEPROVOST @ 2006-05-24 16:43 ` Esben Nielsen 2006-05-24 17:06 ` Thomas Gleixner 2006-05-24 17:30 ` Ingo's realtime_preempt patch causes kernel oops Sven-Thorsten Dietrich 2 siblings, 2 replies; 34+ messages in thread From: Esben Nielsen @ 2006-05-24 16:43 UTC (permalink / raw) To: Steven Rostedt Cc: Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner On Wed, 24 May 2006, Steven Rostedt wrote: > On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@wavecom.fr wrote: > [...] > > Thomas or Ingo, > > Maybe the handling of IRQs needs to handle the case that shared irq can > have both a NODELAY and a thread. The irq descriptor could have a > NODELAY set if any of the actions are NODELAY, but before calling the > interrupt handler (in interrupt context), check if the action is NODELAY > or not, and if not, wake up the thread if not done so already. > > thoughts? > I am working on patchset dealing with this problem. It still needs clean up. The basic idea is to add a SA_MUSTTHREAD along with SA_NODELAY. Under PREEMPT_RT all interrupthandlers, which doesn't have SA_NODELAY, will get SA_MUSTTHREAD unless the driver is changed. In irq_request() it is checked if the handler has SA_NODELAY and an old has SA_MUSTTHREAD and visa versa. I have also made a lock type which can be changed from rt_mutex to raw_spin_lock runtime. And I have made a system with a call-back from the irq-layer to the driver so they can change their spinlocks on the fly when needed. Esben > -- Steve > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 16:43 ` Esben Nielsen @ 2006-05-24 17:06 ` Thomas Gleixner 2006-05-24 18:00 ` Sven-Thorsten Dietrich 2006-05-24 17:30 ` Ingo's realtime_preempt patch causes kernel oops Sven-Thorsten Dietrich 1 sibling, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-24 17:06 UTC (permalink / raw) To: Esben Nielsen Cc: Steven Rostedt, Yann.LEPROVOST, Daniel Walker, linux-kernel, Ingo Molnar On Wed, 2006-05-24 at 18:43 +0200, Esben Nielsen wrote: > I am working on patchset dealing with this problem. It still needs clean > up. The basic idea is to add a SA_MUSTTHREAD along with SA_NODELAY. Under > PREEMPT_RT all interrupthandlers, which doesn't have SA_NODELAY, will get > SA_MUSTTHREAD unless the driver is changed. In irq_request() it is checked > if the handler has SA_NODELAY and an old has SA_MUSTTHREAD and visa > versa. > > I have also made a lock type which can be changed from rt_mutex to > raw_spin_lock runtime. And I have made a system with a call-back from the > irq-layer to the driver so they can change their spinlocks on the fly when > needed. That sounds scary. If you want your handler to be SA_NODELAY then you did this for a reason. Simply refuse to share if the other device requests the interrupt without SA_NODELAY. A real solution for that problem needs more thought and the only thing which comes to my mind is to have split handler functionality, which allows to implement real cascaded interrupts. The short first stub would just query, mask/ack the interrupt in the device and return the appropriate information, so the real handler can be invoked at any given time. I know it would be a large pile of hacking, but it would be a clean solution. OTOH it might be done gradually on a per driver base once the basic infrastucture is in place. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 17:06 ` Thomas Gleixner @ 2006-05-24 18:00 ` Sven-Thorsten Dietrich 2006-05-30 10:00 ` RT_PREEMPT problem with cascaded irqchip Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Sven-Thorsten Dietrich @ 2006-05-24 18:00 UTC (permalink / raw) To: tglx Cc: Esben Nielsen, Steven Rostedt, Yann.LEPROVOST, Daniel Walker, linux-kernel, Ingo Molnar On Wed, 2006-05-24 at 19:06 +0200, Thomas Gleixner wrote: > On Wed, 2006-05-24 at 18:43 +0200, Esben Nielsen wrote: > > I am working on patchset dealing with this problem. It still needs clean > > up. The basic idea is to add a SA_MUSTTHREAD along with SA_NODELAY. Under > > PREEMPT_RT all interrupthandlers, which doesn't have SA_NODELAY, will get > > SA_MUSTTHREAD unless the driver is changed. In irq_request() it is checked > > if the handler has SA_NODELAY and an old has SA_MUSTTHREAD and visa > > versa. > > > > I have also made a lock type which can be changed from rt_mutex to > > raw_spin_lock runtime. And I have made a system with a call-back from the > > irq-layer to the driver so they can change their spinlocks on the fly when > > needed. > > That sounds scary. > > If you want your handler to be SA_NODELAY then you did this for a > reason. Simply refuse to share if the other device requests the > interrupt without SA_NODELAY. > This is apparently difficult with COTS hardware in some cases. > A real solution for that problem needs more thought and the only thing > which comes to my mind is to have split handler functionality, which > allows to implement real cascaded interrupts. The short first stub would > just query, mask/ack the interrupt in the device and return the > appropriate information, so the real handler can be invoked at any given > time. > > I know it would be a large pile of hacking, but it would be a clean > solution. OTOH it might be done gradually on a per driver base once the > basic infrastucture is in place. > The problem with the per-driver approach to porting, is that this is only possible if you have a limited (known) number of devices in your system. There is code which promotes any IRQ shared with SA_NODELAY to SA_NODELAY, and at least on PCI, that is where you get cascading collisions between the drivers that have been adapted with the ones that have not. Sven > tglx > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- *********************************** Sven-Thorsten Dietrich Real-Time Software Architect MontaVista Software, Inc. 2901 Patrick Henry Drive, Suite 150 Santa Clara, CA 95054-1831 Direct: 408.572.7870 Main: 408.572.8000 Fax: 408.572.8005 www.mvista.com Platform To Innovate *********************************** ^ permalink raw reply [flat|nested] 34+ messages in thread
* RT_PREEMPT problem with cascaded irqchip 2006-05-24 18:00 ` Sven-Thorsten Dietrich @ 2006-05-30 10:00 ` Yann.LEPROVOST 2006-05-30 10:27 ` Thomas Gleixner 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-30 10:00 UTC (permalink / raw) To: Sven-Thorsten Dietrich Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, tglx Hi folks, After shared interrupt line with CONFIG_PREEMPT_HARDIRQS issue, I found another problem with the gpio "interrupt on level change" management on AT91RM9200. >From the point of view of linux, there is to struct irqchip : - one dealing with the interrupt controller (AIC) - another one dealing with PIO controllers to mask and unmask interrupts from gpios The second one is cascaded with the first one through 4 irq lines (one for each PIO controller, therefore 4 PIO controllers) using set_irq_chained_handler. After registering theses irqs, the gpio_irq_handler is correctly called on gpio irqs... However, when calling desc->chip->mask, the function at91rm9200_mask_irq is called instead of gpio_mask_irq ! at91rm9200_mask_irq is registered on the first AIC struct irqchip. I'm using linux-2.6.16-at91-rt23 with CONFIG_PREEMPT_HARDIRQS=yes I have rewrite gpio_irq_handler as : static void gpio_irq_handler(unsigned int irq, struct irqdesc* desc, struct pt_regs* regs) { desc->chip->mask(irq); desc->chip->unmask(irq); } As desc->chip->(un)mask(irq) doesn't acknowledge the PIO controller, kernel loops in ISR... What's wrong with desc->chip->mask ? Regards Yann Leprovost ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 10:00 ` RT_PREEMPT problem with cascaded irqchip Yann.LEPROVOST @ 2006-05-30 10:27 ` Thomas Gleixner 2006-05-30 10:26 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-30 10:27 UTC (permalink / raw) To: Yann.LEPROVOST Cc: Sven-Thorsten Dietrich, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen On Tue, 2006-05-30 at 12:00 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Hi folks, > > However, when calling desc->chip->mask, the function at91rm9200_mask_irq is > called instead of gpio_mask_irq ! Well, propably the chip setting of the gpio interrupts is not correct. Can you show me the code please ? tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 10:27 ` Thomas Gleixner @ 2006-05-30 10:26 ` Yann.LEPROVOST 2006-05-30 11:22 ` Thomas Gleixner 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-30 10:26 UTC (permalink / raw) To: tglx Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich Of course, here is the file arch/arm/mach-at91rm9200/gpio.c with my modified gpio_irq_handler. /* * linux/arch/arm/mach-at91rm9200/gpio.c * * Copyright (C) 2005 HP Labs * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ #include <linux/errno.h> #include <linux/kernel.h> #include <linux/list.h> #include <linux/module.h> #include <linux/interrupt.h> #include <linux/kernel_stat.h> #include <asm/io.h> #include <asm/mach/irq.h> #include <asm/arch/hardware.h> #include <asm/arch/gpio.h> static const u32 pio_controller_offset[4] = { AT91_PIOA, AT91_PIOB, AT91_PIOC, AT91_PIOD, }; static inline void __iomem *pin_to_controller(unsigned pin) { void __iomem *sys_base = (void __iomem *) AT91_VA_BASE_SYS; pin -= PIN_BASE; pin /= 32; if (likely(pin < BGA_GPIO_BANKS)) return sys_base + pio_controller_offset[pin]; return NULL; } static inline unsigned pin_to_mask(unsigned pin) { pin -= PIN_BASE; return 1 << (pin % 32); } /*--------------------------------------------------------------------------*/ /* Not all hardware capabilities are exposed through these calls; they * only encapsulate the most common features and modes. (So if you * want to change signals in groups, do it directly.) * * Bootloaders will usually handle some of the pin multiplexing setup. * The intent is certainly that by the time Linux is fully booted, all * pins should have been fully initialized. These setup calls should * only be used by board setup routines, or possibly in driver probe(). * * For bootloaders doing all that setup, these calls could be inlined * as NOPs so Linux won't duplicate any setup code */ /* * mux the pin to the "A" internal peripheral role. */ int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + PIO_IDR); __raw_writel(mask, pio + (use_pullup ? PIO_PUER : PIO_PUDR)); __raw_writel(mask, pio + PIO_ASR); __raw_writel(mask, pio + PIO_PDR); return 0; } EXPORT_SYMBOL(at91_set_A_periph); /* * mux the pin to the "B" internal peripheral role. */ int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + PIO_IDR); __raw_writel(mask, pio + (use_pullup ? PIO_PUER : PIO_PUDR)); __raw_writel(mask, pio + PIO_BSR); __raw_writel(mask, pio + PIO_PDR); return 0; } EXPORT_SYMBOL(at91_set_B_periph); /* * mux the pin to the gpio controller (instead of "A" or "B" peripheral), and * configure it for an input. */ int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + PIO_IDR); __raw_writel(mask, pio + (use_pullup ? PIO_PUER : PIO_PUDR)); __raw_writel(mask, pio + PIO_ODR); __raw_writel(mask, pio + PIO_PER); return 0; } EXPORT_SYMBOL(at91_set_gpio_input); /* * mux the pin to the gpio controller (instead of "A" or "B" peripheral), * and configure it for an output. */ int __init_or_module at91_set_gpio_output(unsigned pin, int value) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + PIO_IDR); __raw_writel(mask, pio + PIO_PUDR); __raw_writel(mask, pio + (value ? PIO_SODR : PIO_CODR)); __raw_writel(mask, pio + PIO_OER); __raw_writel(mask, pio + PIO_PER); return 0; } EXPORT_SYMBOL(at91_set_gpio_output); /* * enable/disable the glitch filter; mostly used with IRQ handling. */ int __init_or_module at91_set_deglitch(unsigned pin, int is_on) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + (is_on ? PIO_IFER : PIO_IFDR)); return 0; } EXPORT_SYMBOL(at91_set_deglitch); /* * enable/disable the multi-driver; This is only valid for output and * allows the output pin to run as an open collector output. */ int __init_or_module at91_set_multi_drive(unsigned pin, int is_on) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + (is_on ? PIO_MDER : PIO_MDDR)); return 0; } EXPORT_SYMBOL(at91_set_multi_drive); /*--------------------------------------------------------------------------*/ /* * assuming the pin is muxed as a gpio output, set its value. */ int at91_set_gpio_value(unsigned pin, int value) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (!pio) return -EINVAL; __raw_writel(mask, pio + (value ? PIO_SODR : PIO_CODR)); return 0; } EXPORT_SYMBOL(at91_set_gpio_value); /* * read the pin's value (works even if it's not muxed as a gpio). */ int at91_get_gpio_value(unsigned pin) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); u32 pdsr; if (!pio) return -EINVAL; pdsr = __raw_readl(pio + PIO_PDSR); return (pdsr & mask) != 0; } EXPORT_SYMBOL(at91_get_gpio_value); /*--------------------------------------------------------------------------*/ /* Several AIC controller irqs are dispatched through this GPIO handler. * To use any AT91_PIN_* as an externally triggered IRQ, first call * at91_set_gpio_input() then maybe enable its glitch filter. * Then just request_irq() with the pin ID; it works like any ARM IRQ * handler, though it always triggers on rising and falling edges. * * Alternatively, certain pins may be used directly as IRQ0..IRQ6 after * configuring them with at91_set_a_periph() or at91_set_b_periph(). * IRQ0..IRQ6 should be configurable, e.g. level vs edge triggering. */ static void gpio_irq_mask(unsigned pin) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (pio) __raw_writel(mask, pio + PIO_IDR); } static void gpio_irq_unmask(unsigned pin) { void __iomem *pio = pin_to_controller(pin); unsigned mask = pin_to_mask(pin); if (pio) __raw_writel(mask, pio + PIO_IER); } static int gpio_irq_type(unsigned pin, unsigned type) { return (type == IRQT_BOTHEDGE) ? 0 : -EINVAL; } static struct irqchip gpio_irqchip = { .mask = gpio_irq_mask, .unmask = gpio_irq_unmask, .set_type = gpio_irq_type, }; static void gpio_irq_handler(unsigned irq, struct irqdesc *desc, struct pt_regs *regs) { desc->chip->mask(irq); desc->chip->unmask(irq); } static DEFINE_IRQ_CHAINED_TYPE(gpio_irq_handler); /* call this from board-specific init_irq */ void __init at91_gpio_irq_setup(unsigned banks) { unsigned pioc, pin, id; if (banks > 4) banks = 4; for (pioc = 0, pin = PIN_BASE, id = AT91_ID_PIOA; pioc < banks; pioc++, id++) { void __iomem *controller; unsigned i; controller = (void __iomem *) AT91_VA_BASE_SYS + pio_controller_offset[pioc]; __raw_writel(~0, controller + PIO_IDR); set_irq_data(id, (void *) pin); set_irq_chipdata(id, (void __force *) controller); for (i = 0; i < 32; i++, pin++) { set_irq_chip(pin, &gpio_irqchip); printk(KERN_ERR "GPIO SET_IRQ_CHIP\n"); set_irq_handler(pin, do_simple_IRQ); set_irq_flags(pin, IRQF_VALID); } set_irq_chained_handler(id, gpio_irq_handler); /* enable the PIO peripheral clock */ at91_sys_write(AT91_PMC_PCER, 1 << id); } pr_info("AT91: %d gpio irqs in %d banks\n", pin - PIN_BASE, banks); } Thomas Gleixner <tglx@linutronix. de> To Sent by: Yann.LEPROVOST@wavecom.fr linux-kernel-owne cc r@vger.kernel.org Sven-Thorsten Dietrich <sven@mvista.com>, Daniel Walker <dwalker@mvista.com>, 30/05/2006 12:27 linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org, Ingo Molnar <mingo@elte.hu>, Steven Please respond to Rostedt <rostedt@goodmis.org>, tglx@linutronix.d Esben Nielsen <simlo@phys.au.dk> e Subject Re: RT_PREEMPT problem with cascaded irqchip On Tue, 2006-05-30 at 12:00 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Hi folks, > > However, when calling desc->chip->mask, the function at91rm9200_mask_irq is > called instead of gpio_mask_irq ! Well, propably the chip setting of the gpio interrupts is not correct. Can you show me the code please ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 10:26 ` Yann.LEPROVOST @ 2006-05-30 11:22 ` Thomas Gleixner 2006-05-30 14:44 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-30 11:22 UTC (permalink / raw) To: Yann.LEPROVOST Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich On Tue, 2006-05-30 at 12:26 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Of course, here is the file arch/arm/mach-at91rm9200/gpio.c with my > modified gpio_irq_handler. > for (i = 0; i < 32; i++, pin++) { > set_irq_chip(pin, &gpio_irqchip); > printk(KERN_ERR "GPIO SET_IRQ_CHIP\n"); > set_irq_handler(pin, do_simple_IRQ); -----------------------------------------^^^^^^^^^^^^^^^ Care to look into the implementation of this ? As the name says, its simple. It does no ack/mask whatever. Use the level resp. the edge handler instead. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 11:22 ` Thomas Gleixner @ 2006-05-30 14:44 ` Yann.LEPROVOST 2006-05-30 23:25 ` Thomas Gleixner 0 siblings, 1 reply; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-30 14:44 UTC (permalink / raw) To: tglx Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich Well, in fact the issue doesn't come neither from the mask/unmask procedure nor from the set_irq calls. Correct gpio mask/unmask are called before the gpio_irq_handler. However, there is an issue in gpio_irq_handler (specific to generic_irq and AT91RM9200, i think) concerning desc->chip->chip_data. The following change has to be applied : -- pio = (void __force __iomem *) desc->chip->chip_data; ++ pio = (void __force __iomem *) desc->chip_data; Moreover, I think that the call to redirect_hardirq have to be insered in gpio_irq_handler but I don't know how to do that. Regards Yann Leprovost Thomas Gleixner <tglx@linutronix. de> To Sent by: Yann.LEPROVOST@wavecom.fr linux-kernel-owne cc r@vger.kernel.org Daniel Walker <dwalker@mvista.com>, linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org, 30/05/2006 13:22 Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>, Esben Nielsen <simlo@phys.au.dk>, Please respond to Sven-Thorsten Dietrich tglx@linutronix.d <sven@mvista.com> e Subject Re: RT_PREEMPT problem with cascaded irqchip On Tue, 2006-05-30 at 12:26 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Of course, here is the file arch/arm/mach-at91rm9200/gpio.c with my > modified gpio_irq_handler. > for (i = 0; i < 32; i++, pin++) { > set_irq_chip(pin, &gpio_irqchip); > printk(KERN_ERR "GPIO SET_IRQ_CHIP\n"); > set_irq_handler(pin, do_simple_IRQ); -----------------------------------------^^^^^^^^^^^^^^^ Care to look into the implementation of this ? As the name says, its simple. It does no ack/mask whatever. Use the level resp. the edge handler instead. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 14:44 ` Yann.LEPROVOST @ 2006-05-30 23:25 ` Thomas Gleixner 2006-05-31 8:26 ` Yann.LEPROVOST 0 siblings, 1 reply; 34+ messages in thread From: Thomas Gleixner @ 2006-05-30 23:25 UTC (permalink / raw) To: Yann.LEPROVOST Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich Yann, Can you please use a sane mail client ? There is no point to have the headers of the previous mail inserted in some fancy way. Also please answer inline and not on top of the reply. Thanks. On Tue, 2006-05-30 at 16:44 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Well, in fact the issue doesn't come neither from the mask/unmask procedure > nor from the set_irq calls. > Correct gpio mask/unmask are called before the gpio_irq_handler. > > However, there is an issue in gpio_irq_handler (specific to generic_irq and > AT91RM9200, i think) concerning desc->chip->chip_data. > The following change has to be applied : > > -- pio = (void __force __iomem *) desc->chip->chip_data; > ++ pio = (void __force __iomem *) desc->chip_data; Hmm. Is that part of your code or is it related to code in mainline ? > Moreover, I think that the call to redirect_hardirq have to be insered in > gpio_irq_handler but I don't know how to do that. Why should that be done. The gpio_irq_handler should be called from the demultiplexing handler, via desc->handler(..). ARM has a conversion macro - desc_handle_irq() for that. Anyway, the ARM code in 2.6.16-rtXX is lacking some of the changes we did in the genirq patchset. Sorry: - ENOTENOUGHINSTANCES I'm in the progress to update that. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: RT_PREEMPT problem with cascaded irqchip 2006-05-30 23:25 ` Thomas Gleixner @ 2006-05-31 8:26 ` Yann.LEPROVOST 0 siblings, 0 replies; 34+ messages in thread From: Yann.LEPROVOST @ 2006-05-31 8:26 UTC (permalink / raw) To: tglx Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich > Yann, > > Can you please use a sane mail client ? There is no point to have the > headers of the previous mail inserted in some fancy way. Also please > answer inline and not on top of the reply. > > Thanks. Sorry for the behavior of my mail client, I have unfortunately no chance to change it. However, I think you'll prefer this format. > > On Tue, 2006-05-30 at 16:44 +0200, Yann.LEPROVOST@wavecom.fr wrote: > > Well, in fact the issue doesn't come neither from the mask/unmask procedure > > nor from the set_irq calls. > > Correct gpio mask/unmask are called before the gpio_irq_handler. > > > > However, there is an issue in gpio_irq_handler (specific to generic_irq and > > AT91RM9200, i think) concerning desc->chip->chip_data. > > The following change has to be applied : > > > > -- pio = (void __force __iomem *) desc->chip->chip_data; > > ++ pio = (void __force __iomem *) desc->chip_data; > > Hmm. Is that part of your code or is it related to code in mainline ? This is currently part of the 2.6.16 mainline! However, I have seen that this line has been replaced by "pio = get_irq_chip_data(irq);" in 2.6.17-rc4-genirq4 which access desc->chip_data. So this problem has been solved by genirq4... > > > Moreover, I think that the call to redirect_hardirq have to be insered in > > gpio_irq_handler but I don't know how to do that. > > Why should that be done. The gpio_irq_handler should be called from the > demultiplexing handler, via desc->handler(..). ARM has a conversion > macro - desc_handle_irq() for that. > Yep, I misunderstood the role of gpio_irq_handler... > Anyway, the ARM code in 2.6.16-rtXX is lacking some of the changes we > did in the genirq patchset. Sorry: - ENOTENOUGHINSTANCES > > I'm in the progress to update that. > > tglx > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-24 16:43 ` Esben Nielsen 2006-05-24 17:06 ` Thomas Gleixner @ 2006-05-24 17:30 ` Sven-Thorsten Dietrich 1 sibling, 0 replies; 34+ messages in thread From: Sven-Thorsten Dietrich @ 2006-05-24 17:30 UTC (permalink / raw) To: Esben Nielsen Cc: Steven Rostedt, Yann.LEPROVOST, Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar, Thomas Gleixner On Wed, 2006-05-24 at 18:43 +0200, Esben Nielsen wrote: > On Wed, 24 May 2006, Steven Rostedt wrote: > > > On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@wavecom.fr wrote: > > [...] > > > > Thomas or Ingo, > > > > Maybe the handling of IRQs needs to handle the case that shared irq can > > have both a NODELAY and a thread. The irq descriptor could have a > > NODELAY set if any of the actions are NODELAY, but before calling the > > interrupt handler (in interrupt context), check if the action is NODELAY > > or not, and if not, wake up the thread if not done so already. > > > > thoughts? > > > > I am working on patchset dealing with this problem. It still needs clean > up. The basic idea is to add a SA_MUSTTHREAD along with SA_NODELAY. Under > PREEMPT_RT all interrupthandlers, which doesn't have SA_NODELAY, will get > SA_MUSTTHREAD unless the driver is changed. In irq_request() it is checked > if the handler has SA_NODELAY and an old has SA_MUSTTHREAD and visa > versa. > Its easy for some drivers to be divided into lockless portions, which can run as SA_NODELAY. If these are kept short (minimum prevent the device from re-asserting the IRQ once it is unmasked), then it should be able to share certain devices on PCI, for example. In a sense, this is how the drivers should be designed, but of course in practice its not always ideal... > I have also made a lock type which can be changed from rt_mutex to > raw_spin_lock runtime. And I have made a system with a call-back from the > irq-layer to the driver so they can change their spinlocks on the fly when > needed. > Sven ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <OF928FB2B7.5CE25C69-ONC1257177.00596B7A-C1257177.005AAA6F@wavecom.fr>]
* Re: Ingo's realtime_preempt patch causes kernel oops [not found] <OF928FB2B7.5CE25C69-ONC1257177.00596B7A-C1257177.005AAA6F@wavecom.fr> @ 2006-05-23 16:38 ` Daniel Walker 2006-05-23 16:44 ` Thomas Gleixner 0 siblings, 1 reply; 34+ messages in thread From: Daniel Walker @ 2006-05-23 16:38 UTC (permalink / raw) To: Yann.LEPROVOST Cc: sdietrich, Takeharu KATO, linux-kernel, Thomas Gleixner, Ingo Molnar On Tue, 2006-05-23 at 18:24 +0200, Yann.LEPROVOST@wavecom.fr wrote: > Yeah that's it , I tested with SA_NODELAY and oops disappears, kernel > doesn't freeze !! > > However, the IRQ 1 line is shared between many peripherals in the > AT91RM9200... > IRQ 1 is the system interrupt. > > From AT91RM9200 datasheet : > > "The System Interrupt is the wired-OR of the interrupt signals coming from: > • the Memory Controller > • the Debug Unit > • the System Timer > • the Real-Time Clock > • the Power Management Controller" > You might have some more issues , cause if you share an SA_NODELAY handler every handler on that interrupt line becomes an SA_NODELAY handler .. So you'll have to go make sure non of those other handlers lock spinlock_t types .. Daniel ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ingo's realtime_preempt patch causes kernel oops 2006-05-23 16:38 ` Daniel Walker @ 2006-05-23 16:44 ` Thomas Gleixner 0 siblings, 0 replies; 34+ messages in thread From: Thomas Gleixner @ 2006-05-23 16:44 UTC (permalink / raw) To: Daniel Walker Cc: Yann.LEPROVOST, sdietrich, Takeharu KATO, linux-kernel, Ingo Molnar On Tue, 2006-05-23 at 09:38 -0700, Daniel Walker wrote: > On Tue, 2006-05-23 at 18:24 +0200, Yann.LEPROVOST@wavecom.fr wrote: > > Yeah that's it , I tested with SA_NODELAY and oops disappears, kernel > > doesn't freeze !! > > > > However, the IRQ 1 line is shared between many peripherals in the > > AT91RM9200... > > IRQ 1 is the system interrupt. > > > > From AT91RM9200 datasheet : > > > > "The System Interrupt is the wired-OR of the interrupt signals coming from: > > • the Memory Controller > > • the Debug Unit > > • the System Timer > > • the Real-Time Clock > > • the Power Management Controller" > > > > You might have some more issues , cause if you share an SA_NODELAY > handler every handler on that interrupt line becomes an SA_NODELAY > handler .. So you'll have to go make sure non of those other handlers > lock spinlock_t types .. The best solution is probably a demultiplex handler. tglx ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2006-05-31 8:32 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-05-23 13:40 Ingo's realtime_preempt patch causes kernel oops Yann.LEPROVOST 2006-05-23 14:09 ` Steven Rostedt 2006-05-23 14:19 ` Steven Rostedt 2006-05-23 14:26 ` Thomas Gleixner 2006-05-23 15:33 ` Daniel Walker 2006-05-23 16:02 ` Steven Rostedt 2006-05-23 16:27 ` Yann.LEPROVOST 2006-05-23 17:00 ` Steven Rostedt 2006-05-23 17:10 ` Yann.LEPROVOST 2006-05-23 18:21 ` Steven Rostedt 2006-05-24 8:06 ` Yann.LEPROVOST 2006-05-24 12:55 ` Steven Rostedt 2006-05-24 13:13 ` Thomas Gleixner 2006-05-24 15:32 ` Sven-Thorsten Dietrich 2006-05-24 15:52 ` Steven Rostedt 2006-05-24 16:03 ` Thomas Gleixner 2006-05-24 16:38 ` Steven Rostedt 2006-05-24 16:55 ` Thomas Gleixner 2006-05-24 17:09 ` Sven-Thorsten Dietrich 2006-05-24 16:06 ` Daniel Walker 2006-05-24 13:58 ` Yann.LEPROVOST 2006-05-24 16:43 ` Esben Nielsen 2006-05-24 17:06 ` Thomas Gleixner 2006-05-24 18:00 ` Sven-Thorsten Dietrich 2006-05-30 10:00 ` RT_PREEMPT problem with cascaded irqchip Yann.LEPROVOST 2006-05-30 10:27 ` Thomas Gleixner 2006-05-30 10:26 ` Yann.LEPROVOST 2006-05-30 11:22 ` Thomas Gleixner 2006-05-30 14:44 ` Yann.LEPROVOST 2006-05-30 23:25 ` Thomas Gleixner 2006-05-31 8:26 ` Yann.LEPROVOST 2006-05-24 17:30 ` Ingo's realtime_preempt patch causes kernel oops Sven-Thorsten Dietrich [not found] <OF928FB2B7.5CE25C69-ONC1257177.00596B7A-C1257177.005AAA6F@wavecom.fr> 2006-05-23 16:38 ` Daniel Walker 2006-05-23 16:44 ` Thomas Gleixner
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).