LinuxLists.cc - Ingo's realtime_preempt patch causes kernel oops

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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, [email protected] 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 [email protected]
> 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

2006-05-23 14:19:57

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

(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, [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2006-05-23 15:33:48

by Daniel Walker

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-23 16:02:44

[permalink] [raw]

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
};

2006-05-23 16:33:22

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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 <[email protected]>
23/05/2006 18:02 cc
[email protected],
[email protected],
Thomas Gleixner
<[email protected]>, Ingo Molnar
<[email protected]>
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
};

2006-05-23 16:38:51

by Daniel Walker

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Tue, 2006-05-23 at 18:24 +0200, [email protected] 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

2006-05-23 17:01:11

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Tue, 2006-05-23 at 18:27 +0200, [email protected] 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

2006-05-23 17:16:36

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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: [email protected]
linux-kernel-owne cc
[email protected] Daniel Walker <[email protected]>,
[email protected], Ingo
Molnar <[email protected]>, Thomas
23/05/2006 19:00 Gleixner <[email protected]>
Subject
Re: Ingo's realtime_preempt patch
causes kernel oops

On Tue, 2006-05-23 at 18:27 +0200, [email protected] 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

2006-05-23 18:22:00

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Tue, 2006-05-23 at 19:10 +0200, [email protected] 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

2006-05-24 07:41:20

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Tue, 2006-05-23 at 09:38 -0700, Daniel Walker wrote:
> On Tue, 2006-05-23 at 18:24 +0200, [email protected] 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

2006-05-24 07:41:19

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 08:12:57

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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
[email protected]
23/05/2006 20:21 cc
Daniel Walker <[email protected]>,
[email protected],
[email protected],
Ingo Molnar <[email protected]>, Thomas
Gleixner <[email protected]>
Subject
Re: Ingo's realtime_preempt patch
causes kernel oops

On Tue, 2006-05-23 at 19:10 +0200, [email protected] 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

2006-05-24 12:55:51

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Wed, 2006-05-24 at 10:06 +0200, [email protected] 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

2006-05-24 13:12:47

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 14:04:24

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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
[email protected]
24/05/2006 14:55 cc
Daniel Walker <[email protected]>,
[email protected],
[email protected],
Ingo Molnar <[email protected]>, Thomas
Gleixner <[email protected]>
Subject
Re: Ingo's realtime_preempt patch
causes kernel oops

On Wed, 2006-05-24 at 10:06 +0200, [email protected] 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

2006-05-24 15:32:46

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 15:52:40

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 16:03:18

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 16:06:09

by Daniel Walker

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

> 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

2006-05-24 16:38:27

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 16:43:48

by Esben Nielsen

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

On Wed, 24 May 2006, Steven Rostedt wrote:

> On Wed, 2006-05-24 at 10:06 +0200, [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2006-05-24 16:54:49

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 17:05:57

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

2006-05-24 17:10:05

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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

http://www.mvista.com
Platform To Innovate
***********************************

2006-05-24 17:31:53

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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, [email protected] 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

2006-05-24 18:01:04

[permalink] [raw]

Subject: Re: Ingo's realtime_preempt patch causes kernel oops

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 [email protected]
> 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

http://www.mvista.com
Platform To Innovate
***********************************

2006-05-30 10:06:13

[permalink] [raw]

Subject: RT_PREEMPT problem with cascaded irqchip

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

2006-05-30 10:27:08

[permalink] [raw]

Subject: Re: RT_PREEMPT problem with cascaded irqchip

On Tue, 2006-05-30 at 12:00 +0200, [email protected] 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

2006-05-30 10:32:58

[permalink] [raw]

Subject: Re: RT_PREEMPT problem with cascaded irqchip

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: [email protected]
linux-kernel-owne cc
[email protected] Sven-Thorsten Dietrich
<[email protected]>, Daniel Walker
<[email protected]>,
30/05/2006 12:27 [email protected],
[email protected],
Ingo Molnar <[email protected]>, Steven
Please respond to Rostedt <[email protected]>,
[email protected] Esben Nielsen <[email protected]>
e Subject
Re: RT_PREEMPT problem with
cascaded irqchip

On Tue, 2006-05-30 at 12:00 +0200, [email protected] 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

2006-05-30 11:22:04

[permalink] [raw]

Subject: Re: RT_PREEMPT problem with cascaded irqchip

On Tue, 2006-05-30 at 12:26 +0200, [email protected] 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

2006-05-30 14:51:07

[permalink] [raw]

Subject: Re: RT_PREEMPT problem with cascaded irqchip

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: [email protected]
linux-kernel-owne cc
[email protected] Daniel Walker <[email protected]>,
[email protected],
[email protected],
30/05/2006 13:22 Ingo Molnar <[email protected]>, Steven
Rostedt <[email protected]>,
Esben Nielsen <[email protected]>,
Please respond to Sven-Thorsten Dietrich
[email protected] <[email protected]>
e Subject
Re: RT_PREEMPT problem with
cascaded irqchip

On Tue, 2006-05-30 at 12:26 +0200, [email protected] 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

2006-05-30 23:24:33

[permalink] [raw]

Subject: Re: RT_PREEMPT problem with cascaded irqchip

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, [email protected] 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

2006-05-31 08:32:28