[Xenomai-help] Xenomai problems on pxa

[Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

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

Hello,

I've been successfully using xenomai on a PXA270 board (Colibri from
Toradex) with a custom 2.6.15 kernel and a gcc-3.3.2 toolchain. The
xenomai version was 2.3.1 with adeos arm patch 1.5-08.

Now I try to upgrade the system to a 2.6.20 kernel compiled with a
gcc-4.2.1 toolchain (from CodeSourcery). I want to use xenomai 2.4.1
with adeos arm patch 1.8-03.

Unfortunately xenomai fails partially to run. As I do not know where to
start debugging, I'm going to describe the current behavior. For testing
purpose I use xenomai-trunk (svn 3409). Xenomai is compiled as a module.

During kernel boot, following message appear:

I-pipe 1.8-03: pipeline enabled.
start_kernel(): bug: interrupts were enabled early

The system boots without problems however.

Loading the xenomai modules (for the kernel with attached config) gives
me no error. If I activate 'Detect Soft Lockups' in the kernel
configuration, loading a xeno module other than xeno_nucleus results in
a soft lockup detection however.

Running the latency test in kernel and interrupt mode is OK (at least it
doesen't fail within the first minute). Starting 'latency' in user-space
failes however with following message:

>latency: failed to pend on semaphore, code -1

With debugging knobs enabled (see config) following messages appear in
the kernel log:

>Xenomai: Switching sampling-762 to secondary mode after exception #8 in
kernel-space at 0xbf027e24 (pid 764)

>Xenomai: Switching sampling-762 to secondary mode after exception #8 in
kernel-space at 0xbf02974c (pid 764)

>Xenomai: Switching display-762 to secondary mode after exception #8 in
kernel-space at 0xbf029e00 (pid 763)

And latency gives following additional error message:

>latency: failed to pend on semaphore, code -1

Looking in /proc/xenomai/fault I see some unaligned access exceptions
(exception 8).

The user space part of xenomai is configured with --enable-arm-eabi and
in the kernel eabi is also activated.

Did I forget a configuration at compile time or is there a possible
xenomai problem?

Any hints are welcomed.

Michael




[-- Attachment #2: kernel_config --]
[-- Type: text/plain, Size: 29742 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20.21-CDC-r1
# Sat Jan 12 18:05:41 2008
#
CONFIG_ARM=y
# CONFIG_GENERIC_TIME is not set
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_MTD_XIP=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=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_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=m
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
CONFIG_XENO_OPT_DEBUG_NUCLEUS=y
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
CONFIG_XENO_OPT_DEBUG_TIMERS=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set

#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set

#
# Machine
#
# CONFIG_XENO_HW_FPU is not set

#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=m
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=m
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=m
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_DEBUG_RTDM=y

#
# Drivers
#

#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set

#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
# CONFIG_XENO_DRIVERS_SWITCHTEST is not set

#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# 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_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_PNX4008 is not set
CONFIG_ARCH_PXA=y
# 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

#
# Intel PXA2xx Implementations
#
# CONFIG_ARCH_LUBBOCK is not set
# CONFIG_MACH_LOGICPD_PXA270 is not set
# CONFIG_MACH_MAINSTONE is not set
# CONFIG_ARCH_PXA_IDP is not set
# CONFIG_PXA_SHARPSL is not set
# CONFIG_MACH_TRIZEPS4 is not set
CONFIG_MACH_COLIBRI=y
CONFIG_PXA27x=y

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_IWMMXT=y
CONFIG_XSCALE_PMU=y

#
# Bus support
#

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y

#
# PC-card bridges
#
CONFIG_PCMCIA_PXA2XX=m

#
# Kernel Features
#
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_COMPAT=y
# CONFIG_PREEMPT is not set
# CONFIG_NO_IDLE_HZ is not set
CONFIG_HZ=100
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT 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_RESOURCES_64BIT is not set
CONFIG_ALIGNMENT_TRAP=y

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.1.12:/proj1/colroot/ ip=dhcp console=ttyS0,9600n8 mem=64M"
# CONFIG_XIP_KERNEL is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#

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

#
# Power management options
#
# CONFIG_PM is not set
# CONFIG_APM is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
# CONFIG_PACKET is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 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
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set

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

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

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_ARM_INTEGRATOR is not set
CONFIG_MTD_COLIBRI=y
# CONFIG_MTD_SHARP_SL is not set
# CONFIG_MTD_PLATRAM is not set

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

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND 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=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_IDE_ARM is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set

#
# 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
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP 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

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA 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
#

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_SMC91X is not set
CONFIG_DM9000=y
# CONFIG_SMC911X is not set

#
# Ethernet (1000 Mbit)
#

#
# Ethernet (10000 Mbit)
#

#
# Token Ring devices
#

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
CONFIG_PPP=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_MPPE=y
CONFIG_PPPOE=y
CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

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

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
CONFIG_TOUCHSCREEN_UCB1400=m
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_PXA=y
CONFIG_SERIAL_PXA_CONSOLE=y
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 is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set

#
# 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

#
# 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=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_TIFM_CORE is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB is not set

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ALSA ARM devices
#
CONFIG_SND_PXA2XX_PCM=y
CONFIG_SND_PXA2XX_AC97=y

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y

#
# HID Devices
#
CONFIG_HID=y

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB_ARCH_HAS_EHCI is not set
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set

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

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=y

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=y
CONFIG_MMC_PXA=y
# CONFIG_MMC_TIFM_SD is not set

#
# Real Time Clock
#
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=m

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

#
# RTC drivers
#
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_SA1100=m
# CONFIG_RTC_DRV_TEST is not set
# CONFIG_RTC_DRV_V3020 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_EXT4DEV_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# 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_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# 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_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=2
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_SUMMARY=y
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_CRAMFS is not set
# 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

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

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

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_DEBUG_CONTEXT=y
# CONFIG_IPIPE_TRACE is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FRAME_POINTER=y
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_ERRORS=y
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_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_LRW 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=y
# 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_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_IOMAP_COPY=y

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 12, 2008 8:35 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> Hello,
>
> I've been successfully using xenomai on a PXA270 board (Colibri from
> Toradex) with a custom 2.6.15 kernel and a gcc-3.3.2 toolchain. The
> xenomai version was 2.3.1 with adeos arm patch 1.5-08.
>
> Now I try to upgrade the system to a 2.6.20 kernel compiled with a
> gcc-4.2.1 toolchain (from CodeSourcery). I want to use xenomai 2.4.1
> with adeos arm patch 1.8-03.
>
> Unfortunately xenomai fails partially to run. As I do not know where to
> start debugging, I'm going to describe the current behavior. For testing
> purpose I use xenomai-trunk (svn 3409). Xenomai is compiled as a module.

I have not yet tried to compile Xenomai for ARM in the same conditions
as you, however I see an option that could be the source of problems:
it's the "optimize for size" option. Could you try disabling it ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> On Jan 12, 2008 8:35 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
>> Hello,
>>
>> I've been successfully using xenomai on a PXA270 board (Colibri from
>> Toradex) with a custom 2.6.15 kernel and a gcc-3.3.2 toolchain. The
>> xenomai version was 2.3.1 with adeos arm patch 1.5-08.
>>
>> Now I try to upgrade the system to a 2.6.20 kernel compiled with a
>> gcc-4.2.1 toolchain (from CodeSourcery). I want to use xenomai 2.4.1
>> with adeos arm patch 1.8-03.
>>
>> Unfortunately xenomai fails partially to run. As I do not know where to
>> start debugging, I'm going to describe the current behavior. For testing
>> purpose I use xenomai-trunk (svn 3409). Xenomai is compiled as a module.
> 
> I have not yet tried to compile Xenomai for ARM in the same conditions
> as you, however I see an option that could be the source of problems:
> it's the "optimize for size" option. Could you try disabling it ?
> 
I tested with the "optimize for size" configuration disabled (otherwise
identical config). Unfortunately the behavior is exactly the same. The kernel
modes of 'latency' are working and the user-space mode is failing.

However, if I set a shorter period (latency -p 300 -t 1), the whole system  
crashes after a couple of seconds and following message is displayed:

Xenomai: fatal: xnshadow_relax() failed for thread display-781[782]
 CPU  PID    PRI      TIMEOUT  STAT      NAME
   0  0       -1      0        00400088  ROOT
>  0  782      0      0        00300380  display-781
   0  0       99      1        00000084  timerbench
Master time base: clock=2640545631

[<c002734c>] (show_stack+0x0/0x5c) from [<bf00bf44>] (xnshadow_relax+0x148/0x244 [xeno_nucleus])
[<bf00bdfc>] (xnshadow_relax+0x0/0x244 [xeno_nucleus]) from [<bf005e14>] (xnpod_trap_fault+0xdc/0x1d0 [xeno_nucleus])
[<bf005d38>] (xnpod_trap_fault+0x0/0x1d0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
 r6 = C01EFE70  r5 = 00000000  r4 = 58454E4F
[<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01efec8>] (exception_event+0x58/0x70)
[<c01efe70>] (exception_event+0x0/0x70) from [<c005aa94>] (__ipipe_dispatch_event+0x124/0x1ec)
 r5 = 00000000  r4 = 00000100
[<c005a970>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
[<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
[<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
[<bf009ea0>] (xntimer_tick_aperiodic+0x0/0x25c [xeno_nucleus]) from [<bf001da4>] (xnintr_clock_handler+0x30/0x10c [xeno_nucleus])
[<bf001d74>] (xnintr_clock_handler+0x0/0x10c [xeno_nucleus]) from [<c0059d40>] (__ipipe_sync_stage+0x1fc/0x2d8)
[<c0059b44>] (__ipipe_sync_stage+0x0/0x2d8) from [<c005a51c>] (ipipe_unstall_pipeline_head+0x70/0x80)
[<c005a4ac>] (ipipe_unstall_pipeline_head+0x0/0x80) from [<bf00c264>] (xnshadow_harden+0x104/0x1c0 [xeno_nucleus])
[<bf00c160>] (xnshadow_harden+0x0/0x1c0 [xeno_nucleus]) from [<bf00c3c4>] (losyscall_event+0xa4/0x1ac [xeno_nucleus])
[<bf00c320>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005aa94>] (__ipipe_dispatch_event+0x124/0x1ec)
[<c005a970>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
[<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)

If I switch the 'Soft Lockup Detecten' in the kernel config on again, loading
xenomai modules result in a soft lockup with following message:

BUG: soft lockup detected on CPU#0!
[<c002729c>] (dump_stack+0x0/0x14) from [<c0056c60>] (softlockup_tick+0x8c/0xbc)
[<c0056bd4>] (softlockup_tick+0x0/0xbc) from [<c003ec18>] (run_local_timers+0x18/0x1c)
 r7 = 00000000  r6 = 0000001A  r5 = 00000000  r4 = C3D7C960
[<c003ec00>] (run_local_timers+0x0/0x1c) from [<c003ec50>] (update_process_times+0x34/0x74)
[<c003ec1c>] (update_process_times+0x0/0x74) from [<c00269b4>] (timer_tick+0xd8/0xf0)
 r5 = C033D560  r4 = C0333DC8
[<c00268dc>] (timer_tick+0x0/0xf0) from [<c002df24>] (pxa_timer_interrupt+0x2c/0xa8)
 r5 = C033D560  r4 = C0333DC8
[<c002def8>] (pxa_timer_interrupt+0x0/0xa8) from [<c0056fb4>] (handle_IRQ_event+0x38/0x98)
 r5 = 00000000  r4 = C03199A8
[<c0056f7c>] (handle_IRQ_event+0x0/0x98) from [<c0058708>] (handle_level_irq+0x78/0xf0)
 r7 = C031B428  r6 = 0000001A  r5 = C03199A8  r4 = C0314680
[<c0058690>] (handle_level_irq+0x0/0xf0) from [<c00238ec>] (asm_do_IRQ+0x4c/0x64)
 r7 = C031B428  r6 = 00000000  r5 = 00000000  r4 = C034409C
[<c00238a0>] (asm_do_IRQ+0x0/0x64) from [<c0059f34>] (__ipipe_sync_stage+0x294/0x2d8)
 r5 = C031B428  r4 = 00000000
[<c0059ca0>] (__ipipe_sync_stage+0x0/0x2d8) from [<c005a328>] (__ipipe_unstall_root+0x4c/0x54)
[<c005a2dc>] (__ipipe_unstall_root+0x0/0x54) from [<c005a36c>] (__ipipe_restore_root+0x3c/0x44)
[<c005a330>] (__ipipe_restore_root+0x0/0x44) from [<c0034424>] (vprintk+0x210/0x384)
[<c0034214>] (vprintk+0x0/0x384) from [<c0034610>] (printk+0x78/0x148)
[<c0034598>] (printk+0x0/0x148) from [<bf027430>] (init_module+0x294/0x2f4 [xeno_native])
 r3 = 60000013  r2 = 00000001  r1 = 00000000  r0 = BF034F30
 r7 = BF03BE70  r6 = BF03BE64  r5 = BF03BE58  r4 = BF03BE4C
[<bf02719c>] (init_module+0x0/0x2f4 [xeno_native]) from [<c0054310>] (sys_init_module+0x134/0x15e8)
[<c00541dc>] (sys_init_module+0x0/0x15e8) from [<c0022e44>] (ret_fast_syscall+0x0/0x10)

The system remains usable however. The lockup detection triggers after about
one second only (kernel help states that it should be after 10s). However, if I
measure the time with 'time', I get following result:

$time modprobe xeno_native
$real    0m 32.87s
$user    0m 0.03s
$sys     0m 32.59s

I suppose, something get messed up during module registration.

--------------

In the meantime I compiled xenomai and the 2.6.20 kernel with the toolchain
from ELDK (version 4.1), which does not use EABI. 'latency' is working in all
three modes!

During boot-up I get the same message as before:

I-pipe 1.8-03: pipeline enabled.
start_kernel(): bug: interrupts were enabled early

I'm not sure if this poses a problem however.

Also the soft lockup remains the same:

BUG: soft lockup detected on CPU#0!
[<c0026cfc>] (dump_stack+0x0/0x14) from [<c0058bf4>] (softlockup_tick+0x98/0xb8)
[<c0058b5c>] (softlockup_tick+0x0/0xb8) from [<c0042010>] (run_local_timers+0x18/0x1c)
 r7 = 0000001A  r6 = 00000000  r5 = 00000000  r4 = C02F35F0
[<c0041ff8>] (run_local_timers+0x0/0x1c) from [<c0042410>] (update_process_times+0x44/0x70)
[<c00423cc>] (update_process_times+0x0/0x70) from [<c0026b90>] (timer_tick+0xc8/0xe8)
 r5 = 00000000  r4 = C02F5BB4
[<c0026ac8>] (timer_tick+0x0/0xe8) from [<c002da38>] (pxa_timer_interrupt+0x20/0xa0)
 r5 = 00000000  r4 = C02F5BB4
[<c002da18>] (pxa_timer_interrupt+0x0/0xa0) from [<c0058d08>] (handle_IRQ_event+0x3c/0x94)
[<c0058ccc>] (handle_IRQ_event+0x0/0x94) from [<c005a60c>] (handle_level_irq+0x80/0xd8)
 r7 = 00000340  r6 = 00000000  r5 = 0000001A  r4 = C02F0680
[<c005a58c>] (handle_level_irq+0x0/0xd8) from [<c0023868>] (asm_do_IRQ+0x48/0x60)
 r5 = 00000000  r4 = C0325894
[<c0023820>] (asm_do_IRQ+0x0/0x60) from [<c005bf64>] (__ipipe_sync_stage+0x1fc/0x330)
 r5 = C0321220  r4 = 0000001A
[<c005bd68>] (__ipipe_sync_stage+0x0/0x330) from [<c005c65c>] (__ipipe_walk_pipeline+0x9c/0xcc)
[<c005c5c0>] (__ipipe_walk_pipeline+0x0/0xcc) from [<c0028000>] (__ipipe_handle_irq+0x114/0x158)
 r7 = C0322B04  r6 = 0000001A  r5 = 0000001A  r4 = C0322B00
[<c0027eec>] (__ipipe_handle_irq+0x0/0x158) from [<c0028124>] (__ipipe_grab_irq+0xe0/0x10c)
 r8 = A001EE8C  r7 = C02EFF5C  r6 = 0000001A  r5 = C02EFF90
 r4 = FFFFFFFF
[<c0028044>] (__ipipe_grab_irq+0x0/0x10c) from [<c00229a8>] (__irq_svc+0x28/0x68)
 r7 = C0333C48  r6 = 04000000  r5 = C02EFF90  r4 = FFFFFFFF
[<c0023db8>] (default_idle+0x0/0x6c) from [<c0023cb8>] (cpu_idle+0x38/0x54)
[<c0023c80>] (cpu_idle+0x0/0x54) from [<c0022050>] (rest_init+0x24/0x2c)
 r5 = C0314E2C  r4 = C0324720
[<c002202c>] (rest_init+0x0/0x2c) from [<c0008a64>] (start_kernel+0x1e8/0x240)
[<c000887c>] (start_kernel+0x0/0x240) from [<a0008030>] (0xa0008030)

The time measurement gives more realistic values:

$time modprobe xeno_native
$real    0m1.030s
$user    0m0.020s
$sys     0m0.820s

Running 'latency' with a shorter period doesn't seem to crash.

----------

Well, this is all information I can provide at the moment.

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 14, 2008 4:39 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > On Jan 12, 2008 8:35 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> >> Hello,
> >>
> >> I've been successfully using xenomai on a PXA270 board (Colibri from
> >> Toradex) with a custom 2.6.15 kernel and a gcc-3.3.2 toolchain. The
> >> xenomai version was 2.3.1 with adeos arm patch 1.5-08.
> >>
> >> Now I try to upgrade the system to a 2.6.20 kernel compiled with a
> >> gcc-4.2.1 toolchain (from CodeSourcery). I want to use xenomai 2.4.1
> >> with adeos arm patch 1.8-03.
> >>
> >> Unfortunately xenomai fails partially to run. As I do not know where to
> >> start debugging, I'm going to describe the current behavior. For testing
> >> purpose I use xenomai-trunk (svn 3409). Xenomai is compiled as a module.
> >
> > I have not yet tried to compile Xenomai for ARM in the same conditions
> > as you, however I see an option that could be the source of problems:
> > it's the "optimize for size" option. Could you try disabling it ?
> >
> I tested with the "optimize for size" configuration disabled (otherwise
> identical config). Unfortunately the behavior is exactly the same. The kernel
> modes of 'latency' are working and the user-space mode is failing.
>
> However, if I set a shorter period (latency -p 300 -t 1), the whole system
> crashes after a couple of seconds and following message is displayed:
>
> Xenomai: fatal: xnshadow_relax() failed for thread display-781[782]
>  CPU  PID    PRI      TIMEOUT  STAT      NAME
>    0  0       -1      0        00400088  ROOT
> >  0  782      0      0        00300380  display-781
>    0  0       99      1        00000084  timerbench
> Master time base: clock=2640545631
>
> [<c002734c>] (show_stack+0x0/0x5c) from [<bf00bf44>] (xnshadow_relax+0x148/0x244 [xeno_nucleus])
> [<bf00bdfc>] (xnshadow_relax+0x0/0x244 [xeno_nucleus]) from [<bf005e14>] (xnpod_trap_fault+0xdc/0x1d0 [xeno_nucleus])
> [<bf005d38>] (xnpod_trap_fault+0x0/0x1d0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
>  r6 = C01EFE70  r5 = 00000000  r4 = 58454E4F
> [<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01efec8>] (exception_event+0x58/0x70)
> [<c01efe70>] (exception_event+0x0/0x70) from [<c005aa94>] (__ipipe_dispatch_event+0x124/0x1ec)
>  r5 = 00000000  r4 = 00000100
> [<c005a970>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
> [<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
> [<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
> [<bf009ea0>] (xntimer_tick_aperiodic+0x0/0x25c [xeno_nucleus]) from [<bf001da4>] (xnintr_clock_handler+0x30/0x10c [xeno_nucleus])
> [<bf001d74>] (xnintr_clock_handler+0x0/0x10c [xeno_nucleus]) from [<c0059d40>] (__ipipe_sync_stage+0x1fc/0x2d8)
> [<c0059b44>] (__ipipe_sync_stage+0x0/0x2d8) from [<c005a51c>] (ipipe_unstall_pipeline_head+0x70/0x80)
> [<c005a4ac>] (ipipe_unstall_pipeline_head+0x0/0x80) from [<bf00c264>] (xnshadow_harden+0x104/0x1c0 [xeno_nucleus])
> [<bf00c160>] (xnshadow_harden+0x0/0x1c0 [xeno_nucleus]) from [<bf00c3c4>] (losyscall_event+0xa4/0x1ac [xeno_nucleus])
> [<bf00c320>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005aa94>] (__ipipe_dispatch_event+0x124/0x1ec)
> [<c005a970>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
> [<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)
>
> If I switch the 'Soft Lockup Detecten' in the kernel config on again, loading
> xenomai modules result in a soft lockup with following message:
>
> BUG: soft lockup detected on CPU#0!
> [<c002729c>] (dump_stack+0x0/0x14) from [<c0056c60>] (softlockup_tick+0x8c/0xbc)
> [<c0056bd4>] (softlockup_tick+0x0/0xbc) from [<c003ec18>] (run_local_timers+0x18/0x1c)
>  r7 = 00000000  r6 = 0000001A  r5 = 00000000  r4 = C3D7C960
> [<c003ec00>] (run_local_timers+0x0/0x1c) from [<c003ec50>] (update_process_times+0x34/0x74)
> [<c003ec1c>] (update_process_times+0x0/0x74) from [<c00269b4>] (timer_tick+0xd8/0xf0)
>  r5 = C033D560  r4 = C0333DC8
> [<c00268dc>] (timer_tick+0x0/0xf0) from [<c002df24>] (pxa_timer_interrupt+0x2c/0xa8)
>  r5 = C033D560  r4 = C0333DC8
> [<c002def8>] (pxa_timer_interrupt+0x0/0xa8) from [<c0056fb4>] (handle_IRQ_event+0x38/0x98)
>  r5 = 00000000  r4 = C03199A8
> [<c0056f7c>] (handle_IRQ_event+0x0/0x98) from [<c0058708>] (handle_level_irq+0x78/0xf0)
>  r7 = C031B428  r6 = 0000001A  r5 = C03199A8  r4 = C0314680
> [<c0058690>] (handle_level_irq+0x0/0xf0) from [<c00238ec>] (asm_do_IRQ+0x4c/0x64)
>  r7 = C031B428  r6 = 00000000  r5 = 00000000  r4 = C034409C
> [<c00238a0>] (asm_do_IRQ+0x0/0x64) from [<c0059f34>] (__ipipe_sync_stage+0x294/0x2d8)
>  r5 = C031B428  r4 = 00000000
> [<c0059ca0>] (__ipipe_sync_stage+0x0/0x2d8) from [<c005a328>] (__ipipe_unstall_root+0x4c/0x54)
> [<c005a2dc>] (__ipipe_unstall_root+0x0/0x54) from [<c005a36c>] (__ipipe_restore_root+0x3c/0x44)
> [<c005a330>] (__ipipe_restore_root+0x0/0x44) from [<c0034424>] (vprintk+0x210/0x384)
> [<c0034214>] (vprintk+0x0/0x384) from [<c0034610>] (printk+0x78/0x148)
> [<c0034598>] (printk+0x0/0x148) from [<bf027430>] (init_module+0x294/0x2f4 [xeno_native])
>  r3 = 60000013  r2 = 00000001  r1 = 00000000  r0 = BF034F30
>  r7 = BF03BE70  r6 = BF03BE64  r5 = BF03BE58  r4 = BF03BE4C
> [<bf02719c>] (init_module+0x0/0x2f4 [xeno_native]) from [<c0054310>] (sys_init_module+0x134/0x15e8)
> [<c00541dc>] (sys_init_module+0x0/0x15e8) from [<c0022e44>] (ret_fast_syscall+0x0/0x10)
>
> The system remains usable however. The lockup detection triggers after about
> one second only (kernel help states that it should be after 10s). However, if I
> measure the time with 'time', I get following result:
>
> $time modprobe xeno_native
> $real    0m 32.87s
> $user    0m 0.03s
> $sys     0m 32.59s
>
> I suppose, something get messed up during module registration.
>
> --------------
>
> In the meantime I compiled xenomai and the 2.6.20 kernel with the toolchain
> from ELDK (version 4.1), which does not use EABI. 'latency' is working in all
> three modes!
>
> During boot-up I get the same message as before:
>
> I-pipe 1.8-03: pipeline enabled.
> start_kernel(): bug: interrupts were enabled early
>
> I'm not sure if this poses a problem however.
>
> Also the soft lockup remains the same:
>
> BUG: soft lockup detected on CPU#0!
> [<c0026cfc>] (dump_stack+0x0/0x14) from [<c0058bf4>] (softlockup_tick+0x98/0xb8)
> [<c0058b5c>] (softlockup_tick+0x0/0xb8) from [<c0042010>] (run_local_timers+0x18/0x1c)
>  r7 = 0000001A  r6 = 00000000  r5 = 00000000  r4 = C02F35F0
> [<c0041ff8>] (run_local_timers+0x0/0x1c) from [<c0042410>] (update_process_times+0x44/0x70)
> [<c00423cc>] (update_process_times+0x0/0x70) from [<c0026b90>] (timer_tick+0xc8/0xe8)
>  r5 = 00000000  r4 = C02F5BB4
> [<c0026ac8>] (timer_tick+0x0/0xe8) from [<c002da38>] (pxa_timer_interrupt+0x20/0xa0)
>  r5 = 00000000  r4 = C02F5BB4
> [<c002da18>] (pxa_timer_interrupt+0x0/0xa0) from [<c0058d08>] (handle_IRQ_event+0x3c/0x94)
> [<c0058ccc>] (handle_IRQ_event+0x0/0x94) from [<c005a60c>] (handle_level_irq+0x80/0xd8)
>  r7 = 00000340  r6 = 00000000  r5 = 0000001A  r4 = C02F0680
> [<c005a58c>] (handle_level_irq+0x0/0xd8) from [<c0023868>] (asm_do_IRQ+0x48/0x60)
>  r5 = 00000000  r4 = C0325894
> [<c0023820>] (asm_do_IRQ+0x0/0x60) from [<c005bf64>] (__ipipe_sync_stage+0x1fc/0x330)
>  r5 = C0321220  r4 = 0000001A
> [<c005bd68>] (__ipipe_sync_stage+0x0/0x330) from [<c005c65c>] (__ipipe_walk_pipeline+0x9c/0xcc)
> [<c005c5c0>] (__ipipe_walk_pipeline+0x0/0xcc) from [<c0028000>] (__ipipe_handle_irq+0x114/0x158)
>  r7 = C0322B04  r6 = 0000001A  r5 = 0000001A  r4 = C0322B00
> [<c0027eec>] (__ipipe_handle_irq+0x0/0x158) from [<c0028124>] (__ipipe_grab_irq+0xe0/0x10c)
>  r8 = A001EE8C  r7 = C02EFF5C  r6 = 0000001A  r5 = C02EFF90
>  r4 = FFFFFFFF
> [<c0028044>] (__ipipe_grab_irq+0x0/0x10c) from [<c00229a8>] (__irq_svc+0x28/0x68)
>  r7 = C0333C48  r6 = 04000000  r5 = C02EFF90  r4 = FFFFFFFF
> [<c0023db8>] (default_idle+0x0/0x6c) from [<c0023cb8>] (cpu_idle+0x38/0x54)
> [<c0023c80>] (cpu_idle+0x0/0x54) from [<c0022050>] (rest_init+0x24/0x2c)
>  r5 = C0314E2C  r4 = C0324720
> [<c002202c>] (rest_init+0x0/0x2c) from [<c0008a64>] (start_kernel+0x1e8/0x240)
> [<c000887c>] (start_kernel+0x0/0x240) from [<a0008030>] (0xa0008030)
>
> The time measurement gives more realistic values:
>
> $time modprobe xeno_native
> $real    0m1.030s
> $user    0m0.020s
> $sys     0m0.820s
>
> Running 'latency' with a shorter period doesn't seem to crash.
>
> ----------
>
> Well, this is all information I can provide at the moment.

It looks like we have two issues:
- one issue is that compiling with the EABI toolchain generates a lot
of unaligned access, which causes a crash, when the fault handler gets
invoked at the wrong time. To solve this issue, I will check if we can
allow the unaligned access to be handled in primary mode under some
condition (it will need at least, a valid linux stack)
- another issue is that there is something wrong with Linux timer
interrupt handling, which causes the soft lockups and weird timer
behaviour.

Could you try the following:
in the version compiled without EABI, in Linux file
arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
the do { } while loop in :

        do {
                timer_tick();
#ifndef CONFIG_IPIPE
                OSSR = OSSR_M0;  /* Clear match on timer 0 */
#else /* CONFIG_IPIPE */
                last_jiffy_time += LATCH;
                if (__ipipe_mach_timerstolen)
                        next_match = last_jiffy_time + LATCH;
                else
#endif /* CONFIG_IPIPE */
                next_match = (OSMR0 += LATCH);
        } while( (signed long)(next_match - OSCR) <= 8 );

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> Could you try the following:
> in the version compiled without EABI, in Linux file
> arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
> the do { } while loop in :
> 
>         do {
>                 timer_tick();
> #ifndef CONFIG_IPIPE
>                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
> #else /* CONFIG_IPIPE */
>                 last_jiffy_time += LATCH;
>                 if (__ipipe_mach_timerstolen)
>                         next_match = last_jiffy_time + LATCH;
>                 else
> #endif /* CONFIG_IPIPE */
>                 next_match = (OSMR0 += LATCH);
>         } while( (signed long)(next_match - OSCR) <= 8 );
> 

Gilles, do you mean removing the whole while loop or just removing
'do' and 'while'? I will do the test this afternoon.

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 15, 2008 11:28 AM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> > Could you try the following:
> > in the version compiled without EABI, in Linux file
> > arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
> > the do { } while loop in :
> >
> >         do {
> >                 timer_tick();
> > #ifndef CONFIG_IPIPE
> >                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
> > #else /* CONFIG_IPIPE */
> >                 last_jiffy_time += LATCH;
> >                 if (__ipipe_mach_timerstolen)
> >                         next_match = last_jiffy_time + LATCH;
> >                 else
> > #endif /* CONFIG_IPIPE */
> >                 next_match = (OSMR0 += LATCH);
> >         } while( (signed long)(next_match - OSCR) <= 8 );
> >
>
> Gilles, do you mean removing the whole while loop or just removing
> 'do' and 'while'? I will do the test this afternoon.

I meant just removing the do and while. Sorry for the misunderstanding.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> It looks like we have two issues:
> - one issue is that compiling with the EABI toolchain generates a lot
> of unaligned access, which causes a crash, when the fault handler gets
> invoked at the wrong time. To solve this issue, I will check if we can
> allow the unaligned access to be handled in primary mode under some
> condition (it will need at least, a valid linux stack)
> - another issue is that there is something wrong with Linux timer
> interrupt handling, which causes the soft lockups and weird timer
> behaviour.
> 
> Could you try the following:
> in the version compiled without EABI, in Linux file
> arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
> the do { } while loop in :
> 
>         do {
>                 timer_tick();
> #ifndef CONFIG_IPIPE
>                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
> #else /* CONFIG_IPIPE */
>                 last_jiffy_time += LATCH;
>                 if (__ipipe_mach_timerstolen)
>                         next_match = last_jiffy_time + LATCH;
>                 else
> #endif /* CONFIG_IPIPE */
>                 next_match = (OSMR0 += LATCH);
>         } while( (signed long)(next_match - OSCR) <= 8 );
> 

Gilles, I removed 'do' and 'while' as you suggested but the kernel does
not boot. The last boot messages before the kernel stalls are the following:

...
PID hash table entries: 256 (order: 8, 1024 bytes)
I-pipe 1.8-03: pipeline enabled.
start_kernel(): bug: interrupts were enabled early
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: 64MB = 64MB total
Memory: 61568KB available (2928K code, 279K data, 104K init)

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 15, 2008 1:47 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > It looks like we have two issues:
> > - one issue is that compiling with the EABI toolchain generates a lot
> > of unaligned access, which causes a crash, when the fault handler gets
> > invoked at the wrong time. To solve this issue, I will check if we can
> > allow the unaligned access to be handled in primary mode under some
> > condition (it will need at least, a valid linux stack)
> > - another issue is that there is something wrong with Linux timer
> > interrupt handling, which causes the soft lockups and weird timer
> > behaviour.
> >
> > Could you try the following:
> > in the version compiled without EABI, in Linux file
> > arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
> > the do { } while loop in :
> >
> >         do {
> >                 timer_tick();
> > #ifndef CONFIG_IPIPE
> >                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
> > #else /* CONFIG_IPIPE */
> >                 last_jiffy_time += LATCH;
> >                 if (__ipipe_mach_timerstolen)
> >                         next_match = last_jiffy_time + LATCH;
> >                 else
> > #endif /* CONFIG_IPIPE */
> >                 next_match = (OSMR0 += LATCH);
> >         } while( (signed long)(next_match - OSCR) <= 8 );
> >
>
> Gilles, I removed 'do' and 'while' as you suggested but the kernel does
> not boot. The last boot messages before the kernel stalls are the following:
>
> ...
> PID hash table entries: 256 (order: 8, 1024 bytes)
> I-pipe 1.8-03: pipeline enabled.
> start_kernel(): bug: interrupts were enabled early
> 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: 64MB = 64MB total
> Memory: 61568KB available (2928K code, 279K data, 104K init)

Ok, it means that vanilla linux needs the do { } while loop. Let us
try something else: put back the do and while. And modify the function
pxa_timer_init. Replace:

OSMR0 = OSCR + LATCH;

with:

last_jiffy_time = OSCR;
OSMR0 = last_jiffy_time + LATCH;

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> On Jan 15, 2008 1:47 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> It looks like we have two issues:
>>> - one issue is that compiling with the EABI toolchain generates a lot
>>> of unaligned access, which causes a crash, when the fault handler gets
>>> invoked at the wrong time. To solve this issue, I will check if we can
>>> allow the unaligned access to be handled in primary mode under some
>>> condition (it will need at least, a valid linux stack)
>>> - another issue is that there is something wrong with Linux timer
>>> interrupt handling, which causes the soft lockups and weird timer
>>> behaviour.
>>>
>>> Could you try the following:
>>> in the version compiled without EABI, in Linux file
>>> arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
>>> the do { } while loop in :
>>>
>>>         do {
>>>                 timer_tick();
>>> #ifndef CONFIG_IPIPE
>>>                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
>>> #else /* CONFIG_IPIPE */
>>>                 last_jiffy_time += LATCH;
>>>                 if (__ipipe_mach_timerstolen)
>>>                         next_match = last_jiffy_time + LATCH;
>>>                 else
>>> #endif /* CONFIG_IPIPE */
>>>                 next_match = (OSMR0 += LATCH);
>>>         } while( (signed long)(next_match - OSCR) <= 8 );
>>>
>> Gilles, I removed 'do' and 'while' as you suggested but the kernel does
>> not boot. The last boot messages before the kernel stalls are the following:
>>
>> ...
>> PID hash table entries: 256 (order: 8, 1024 bytes)
>> I-pipe 1.8-03: pipeline enabled.
>> start_kernel(): bug: interrupts were enabled early
>> 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: 64MB = 64MB total
>> Memory: 61568KB available (2928K code, 279K data, 104K init)
> 
> Ok, it means that vanilla linux needs the do { } while loop. Let us
> try something else: put back the do and while. And modify the function
> pxa_timer_init. Replace:
> 
> OSMR0 = OSCR + LATCH;
> 
> with:
> 
> last_jiffy_time = OSCR;
> OSMR0 = last_jiffy_time + LATCH;
> 
Ok, this solved the soft lock-up. This change is obvious (once discovered :-) ) 
because 'last_jiffy_time' is initialised nowhere.

Now, I can load the xeno-* modules without problem. It is also working with
the EABI toolchain. Thanks Gilles.

However, the other problems remain :-(

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 15, 2008 3:03 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> > On Jan 15, 2008 1:47 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> >> Gilles Chanteperdrix wrote:
> >>> It looks like we have two issues:
> >>> - one issue is that compiling with the EABI toolchain generates a lot
> >>> of unaligned access, which causes a crash, when the fault handler gets
> >>> invoked at the wrong time. To solve this issue, I will check if we can
> >>> allow the unaligned access to be handled in primary mode under some
> >>> condition (it will need at least, a valid linux stack)
> >>> - another issue is that there is something wrong with Linux timer
> >>> interrupt handling, which causes the soft lockups and weird timer
> >>> behaviour.
> >>>
> >>> Could you try the following:
> >>> in the version compiled without EABI, in Linux file
> >>> arch/arm/mach-pxa/time.c, function pxa_timer_interrupt, try removing
> >>> the do { } while loop in :
> >>>
> >>>         do {
> >>>                 timer_tick();
> >>> #ifndef CONFIG_IPIPE
> >>>                 OSSR = OSSR_M0;  /* Clear match on timer 0 */
> >>> #else /* CONFIG_IPIPE */
> >>>                 last_jiffy_time += LATCH;
> >>>                 if (__ipipe_mach_timerstolen)
> >>>                         next_match = last_jiffy_time + LATCH;
> >>>                 else
> >>> #endif /* CONFIG_IPIPE */
> >>>                 next_match = (OSMR0 += LATCH);
> >>>         } while( (signed long)(next_match - OSCR) <= 8 );
> >>>
> >> Gilles, I removed 'do' and 'while' as you suggested but the kernel does
> >> not boot. The last boot messages before the kernel stalls are the following:
> >>
> >> ...
> >> PID hash table entries: 256 (order: 8, 1024 bytes)
> >> I-pipe 1.8-03: pipeline enabled.
> >> start_kernel(): bug: interrupts were enabled early
> >> 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: 64MB = 64MB total
> >> Memory: 61568KB available (2928K code, 279K data, 104K init)
> >
> > Ok, it means that vanilla linux needs the do { } while loop. Let us
> > try something else: put back the do and while. And modify the function
> > pxa_timer_init. Replace:
> >
> > OSMR0 = OSCR + LATCH;
> >
> > with:
> >
> > last_jiffy_time = OSCR;
> > OSMR0 = last_jiffy_time + LATCH;
> >
> Ok, this solved the soft lock-up. This change is obvious (once discovered :-) )
> because 'last_jiffy_time' is initialised nowhere.
>
> Now, I can load the xeno-* modules without problem. It is also working with
> the EABI toolchain. Thanks Gilles.
>
> However, the other problems remain :-(

To solve the problem about unaligned accesses, the solution is to put
some print_symbol or show_stack(NULL, NULL) in xnpod_trap_fault. Once
we get the exact location of an unaligned access, disassemble the
kernel or a module at the given location and try and understand why
there is an unaligned access. You can do this yourself if you are in a
hurry, or let me do it if I am able to reproduce the bug on AT91, but
I need to generate a full image with EABI enabled, so it will take
some time.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> To solve the problem about unaligned accesses, the solution is to put
> some print_symbol or show_stack(NULL, NULL) in xnpod_trap_fault. Once
> we get the exact location of an unaligned access, disassemble the
> kernel or a module at the given location and try and understand why
> there is an unaligned access. 

Well, even though I've never done that before I couldn't resist to try it out.

I put a 'show_stack(NULL,NULL)' in 'xnpod_trap_fault' and got following
stack traces:

----

[<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
[<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
 r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
[<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
[<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
 r5 = 00000000  r4 = 00000100
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
[<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
[<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
[<bf028e54>] (rt_timer_inquire+0x0/0xb0 [xeno_native]) from [<bf02c9a0>] (__rt_timer_inquire+0x20/0x7c [xeno_native])
 r7 = BF01C2A4  r6 = C308BEA4  r5 = 00000000  r4 = C308BFB0
[<bf02c980>] (__rt_timer_inquire+0x0/0x7c [xeno_native]) from [<bf00c688>] (hisyscall_event+0x1ac/0x2b8 [xeno_nucleus])
 r6 = C3C2F100  r5 = 00000000  r4 = C308BFB0
[<bf00c4dc>] (hisyscall_event+0x0/0x2b8 [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
[<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)

Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf028e94 (pid 765)

[<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
[<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
 r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
[<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
[<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
 r5 = 00000000  r4 = 00000100
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
[<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
[<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
[<bf02a7d4>] (__rt_task_set_periodic+0x0/0x11c [xeno_native]) from [<bf00c3f8>] (losyscall_event+0xc8/0x1ac [xeno_nucleus])
 r6 = C308BFB0  r5 = 00000001  r4 = 00000022
[<bf00c330>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
[<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)

Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf02a8b0 (pid 765)
latency: failed to set periodic, code -110
warming up...

[<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
[<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
 r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
[<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
[<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
 r5 = 00000000  r4 = 00000100
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
[<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
[<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
[<bf02af24>] (__rt_sem_p+0x0/0xc0 [xeno_native]) from [<bf00c3f8>] (losyscall_event+0xc8/0x1ac [xeno_nucleus])
 r6 = C3B33FB0  r5 = 00000001  r4 = 00000006
[<bf00c330>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
[<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
[<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)

Xenomai: Switching display-763 to secondary mode after exception #8 in kernel-space at 0xbf02afd4 (pid 764)
latency: failed to pend on semaphore, code -1

----

In the first unaligned access, data abort occurs in 'rt_timer_inquire'. 
In this function I put a 'printk' after each C-line. If I didn't mess
the things up this way, data abort occurs at the assignment:

info->period = period;

Looking at the assembler, instruction 'strd' is used to store this 'long long'
variable.

Interestingly, structure 'info' is allocated on the stack in function
'__rt_timer_inquire' which calls 'rt_timer_inquire' and passes 'info' as an
argument.

I'm not sure but the problem could be that 'long long' variables need to be
8-byte aligned in order to allow 'strd' and 'ldrd' instructions. 
See: http://groups.google.ch/group/comp.sys.arm/browse_thread/thread/a4ed79328671521d/2e3bb93e5a59f785

However, I don't know how to make 'info' to be allocated at an 8-byte boundary.

Looking at the assembler of the two other catches (in '__rt_task_set_periodic'
and '__rt_sem_p') shows that both function use also 'strd' and 'ldrd'
instructions. I didn't check if data abort occurred at these instructions however.

> You can do this yourself if you are in a
> hurry, or let me do it if I am able to reproduce the bug on AT91, but
> I need to generate a full image with EABI enabled, so it will take
> some time.

OK, I started with it but I'd like to let you work on this now. I don't have the knowledge
to fiddle with compiler options or using macros or whatever to solve this problem.

Today, I don't have access to the hardware. When needed I can run tests on an other day.

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 16, 2008 11:14 AM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> > To solve the problem about unaligned accesses, the solution is to put
> > some print_symbol or show_stack(NULL, NULL) in xnpod_trap_fault. Once
> > we get the exact location of an unaligned access, disassemble the
> > kernel or a module at the given location and try and understand why
> > there is an unaligned access.
>
> Well, even though I've never done that before I couldn't resist to try it out.
>
> I put a 'show_stack(NULL,NULL)' in 'xnpod_trap_fault' and got following
> stack traces:
>
> ----
>
> [<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
> [<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
>  r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
> [<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
> [<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
>  r5 = 00000000  r4 = 00000100
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
> [<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
> [<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
> [<bf028e54>] (rt_timer_inquire+0x0/0xb0 [xeno_native]) from [<bf02c9a0>] (__rt_timer_inquire+0x20/0x7c [xeno_native])
>  r7 = BF01C2A4  r6 = C308BEA4  r5 = 00000000  r4 = C308BFB0
> [<bf02c980>] (__rt_timer_inquire+0x0/0x7c [xeno_native]) from [<bf00c688>] (hisyscall_event+0x1ac/0x2b8 [xeno_nucleus])
>  r6 = C3C2F100  r5 = 00000000  r4 = C308BFB0
> [<bf00c4dc>] (hisyscall_event+0x0/0x2b8 [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
> [<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)
>
> Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf028e94 (pid 765)
>
> [<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
> [<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
>  r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
> [<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
> [<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
>  r5 = 00000000  r4 = 00000100
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
> [<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
> [<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
> [<bf02a7d4>] (__rt_task_set_periodic+0x0/0x11c [xeno_native]) from [<bf00c3f8>] (losyscall_event+0xc8/0x1ac [xeno_nucleus])
>  r6 = C308BFB0  r5 = 00000001  r4 = 00000022
> [<bf00c330>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
> [<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)
>
> Xenomai: Switching sampling-763 to secondary mode after exception #8 in kernel-space at 0xbf02a8b0 (pid 765)
> latency: failed to set periodic, code -110
> warming up...
>
> [<c002734c>] (show_stack+0x0/0x5c) from [<bf005d88>] (xnpod_trap_fault+0x50/0x1e0 [xeno_nucleus])
> [<bf005d38>] (xnpod_trap_fault+0x0/0x1e0 [xeno_nucleus]) from [<bf002278>] (xnarch_trap_fault+0x20/0x28 [xeno_nucleus])
>  r6 = C01EFFE0  r5 = 00000000  r4 = 58454E4F
> [<bf002258>] (xnarch_trap_fault+0x0/0x28 [xeno_nucleus]) from [<c01f0038>] (exception_event+0x58/0x70)
> [<c01effe0>] (exception_event+0x0/0x70) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
>  r5 = 00000000  r4 = 00000100
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c002b914>] (do_alignment+0x1a4/0x410)
> [<c002b770>] (do_alignment+0x0/0x410) from [<c0029a98>] (do_DataAbort+0x3c/0x13c)
> [<c0029a5c>] (do_DataAbort+0x0/0x13c) from [<c00229ac>] (__dabt_svc+0x4c/0x60)
> [<bf02af24>] (__rt_sem_p+0x0/0xc0 [xeno_native]) from [<bf00c3f8>] (losyscall_event+0xc8/0x1ac [xeno_nucleus])
>  r6 = C3B33FB0  r5 = 00000001  r4 = 00000006
> [<bf00c330>] (losyscall_event+0x0/0x1ac [xeno_nucleus]) from [<c005abf0>] (__ipipe_dispatch_event+0x124/0x1ec)
> [<c005aacc>] (__ipipe_dispatch_event+0x0/0x1ec) from [<c0028270>] (__ipipe_syscall_root+0x5c/0x108)
> [<c0028214>] (__ipipe_syscall_root+0x0/0x108) from [<c0022f7c>] (vector_swi+0x5c/0x98)
>
> Xenomai: Switching display-763 to secondary mode after exception #8 in kernel-space at 0xbf02afd4 (pid 764)
> latency: failed to pend on semaphore, code -1
>
> ----
>
> In the first unaligned access, data abort occurs in 'rt_timer_inquire'.
> In this function I put a 'printk' after each C-line. If I didn't mess
> the things up this way, data abort occurs at the assignment:
>
> info->period = period;
>
> Looking at the assembler, instruction 'strd' is used to store this 'long long'
> variable.
>
> Interestingly, structure 'info' is allocated on the stack in function
> '__rt_timer_inquire' which calls 'rt_timer_inquire' and passes 'info' as an
> argument.
>
> I'm not sure but the problem could be that 'long long' variables need to be
> 8-byte aligned in order to allow 'strd' and 'ldrd' instructions.
> See: http://groups.google.ch/group/comp.sys.arm/browse_thread/thread/a4ed79328671521d/2e3bb93e5a59f785
>
> However, I don't know how to make 'info' to be allocated at an 8-byte boundary.
>
> Looking at the assembler of the two other catches (in '__rt_task_set_periodic'
> and '__rt_sem_p') shows that both function use also 'strd' and 'ldrd'
> instructions. I didn't check if data abort occurred at these instructions however.
>
> > You can do this yourself if you are in a
> > hurry, or let me do it if I am able to reproduce the bug on AT91, but
> > I need to generate a full image with EABI enabled, so it will take
> > some time.
>
> OK, I started with it but I'd like to let you work on this now. I don't have the knowledge
> to fiddle with compiler options or using macros or whatever to solve this problem.
>
> Today, I don't have access to the hardware. When needed I can run tests on an other day.

I do not know how to solve this. From my point of view, this is a
compiler bug: knowing that it uses instructions which needs 8 bytes
alignment, the compiler should align stack frames on 8 bytes
boundaries, period.

gcc for x86 has an option -mpreferred-stack-boundary to allow setting
the stack alignment, but this option does not work on ARM. Maybe we
can try the -mapcs-frame option ? Try adding it in arch/arm/Makefile,

Add if, for instance, to:
CFLAGS_ABI      :=-mabi=aapcs-linux -mno-thumb-interwork

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> I do not know how to solve this. From my point of view, this is a
> compiler bug: knowing that it uses instructions which needs 8 bytes
> alignment, the compiler should align stack frames on 8 bytes
> boundaries, period.

Digging a bit in the mailing lists about stack alignment and EABI I find
that gcc *realy* should handle proper stack alignment.

See http://gcc.gnu.org/ml/gcc/2006-07/msg00030.html
or http://www.codesourcery.com/archives/arm-gnu/msg01467.html

Now, looking at the assembly code for the SWI handler, I see that ipipe
introduces flowing code:

	#ifdef CONFIG_IPIPE
		stmfd	sp!, {r0-r3, ip}
		add	r1, sp, #S_OFF
		add	r1, r1, #20
		mov	r0, scno
		bl	__ipipe_syscall_root
		cmp	r0, #0
		ldmfd	sp!, {r0-r3, ip}
		blt	__ipipe_ret_fast_syscall
		bgt	__ipipe_fast_exit_syscall
	#endif /* CONFIG_IPIPE */

Assuming that the stack was properly aligned before this code snipped
the first instruction moves 20 bytes onto the stack. 20 modulo 8 = 4 which
means, the stack is not 8-byte aligned any more. This could be the reason
why the strd/ldrd instructions are failing later.

I can't verify this on hardware now but I'll do it for sure.

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 16, 2008 3:19 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> > I do not know how to solve this. From my point of view, this is a
> > compiler bug: knowing that it uses instructions which needs 8 bytes
> > alignment, the compiler should align stack frames on 8 bytes
> > boundaries, period.
>
> Digging a bit in the mailing lists about stack alignment and EABI I find
> that gcc *realy* should handle proper stack alignment.
>
> See http://gcc.gnu.org/ml/gcc/2006-07/msg00030.html
> or http://www.codesourcery.com/archives/arm-gnu/msg01467.html
>
> Now, looking at the assembly code for the SWI handler, I see that ipipe
> introduces flowing code:

Of course. I found that suspicious that the kernel code could rely on
suboptimal trap handlers to work correctly, and was about to tell you
to run Linux without Xenomai to see if the unaligned fault counters
incremented in /proc/cpu/alignment

>
>         #ifdef CONFIG_IPIPE
>                 stmfd   sp!, {r0-r3, ip}
>                 add     r1, sp, #S_OFF

You could try adding:
                   add     sp, sp, #4
here
>                 add     r1, r1, #20
>                 mov     r0, scno
>                 bl      __ipipe_syscall_root
>                 cmp     r0, #0
and:
                   sub     sp, sp, #4
here

>                 ldmfd   sp!, {r0-r3, ip}
>                 blt     __ipipe_ret_fast_syscall
>                 bgt     __ipipe_fast_exit_syscall
>         #endif /* CONFIG_IPIPE */
>
> Assuming that the stack was properly aligned before this code snipped
> the first instruction moves 20 bytes onto the stack. 20 modulo 8 = 4 which
> means, the stack is not 8-byte aligned any more. This could be the reason
> why the strd/ldrd instructions are failing later.
>
> I can't verify this on hardware now but I'll do it for sure.

Of course. Almost no need to verify,

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 16, 2008 3:35 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Jan 16, 2008 3:19 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> > Gilles Chanteperdrix wrote:
> > > I do not know how to solve this. From my point of view, this is a
> > > compiler bug: knowing that it uses instructions which needs 8 bytes
> > > alignment, the compiler should align stack frames on 8 bytes
> > > boundaries, period.
> >
> > Digging a bit in the mailing lists about stack alignment and EABI I find
> > that gcc *realy* should handle proper stack alignment.
> >
> > See http://gcc.gnu.org/ml/gcc/2006-07/msg00030.html
> > or http://www.codesourcery.com/archives/arm-gnu/msg01467.html
> >
> > Now, looking at the assembly code for the SWI handler, I see that ipipe
> > introduces flowing code:
>
> Of course. I found that suspicious that the kernel code could rely on
> suboptimal trap handlers to work correctly, and was about to tell you
> to run Linux without Xenomai to see if the unaligned fault counters
> incremented in /proc/cpu/alignment
>
> >
> >         #ifdef CONFIG_IPIPE
> >                 stmfd   sp!, {r0-r3, ip}
> >                 add     r1, sp, #S_OFF
>
> You could try adding:
>                    add     sp, sp, #4
> here
> >                 add     r1, r1, #20
> >                 mov     r0, scno
> >                 bl      __ipipe_syscall_root
> >                 cmp     r0, #0
> and:
>                    sub     sp, sp, #4
> here
>
> >                 ldmfd   sp!, {r0-r3, ip}
> >                 blt     __ipipe_ret_fast_syscall
> >                 bgt     __ipipe_fast_exit_syscall
> >         #endif /* CONFIG_IPIPE */

Stack goes down, so this should be the other way around, substract 4
from sp before, and add 4 to sp after.

I tested it on another arm (without EABI, so I can not know if it
works), and there is at least no regression.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai problems on pxa

[Bernhard Michael]

Gilles Chanteperdrix wrote:
> I tested it on another arm (without EABI, so I can not know if it
> works), and there is at least no regression.
 
I tested it too with the EABI toolchain and its working. Thank you
Gilles for your help.

To sum up, here are the necessary ipipe changes to get xenomai running
on pxa (compiled with an EABI toolchain). 

Kernel: 2.6.20, 
Adeos/Ipipe patch: ipipe-2.6.20-arm-1.8-03

Align the stack pointer to 8-byte boundary:

--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -216,11 +216,12 @@ ENTRY(vector_swi)
        stmdb   sp!, {r4, r5}                   @ push fifth and sixth args
 #ifdef CONFIG_IPIPE
        stmfd   sp!, {r0-r3, ip}
-       add     r1, sp, #S_OFF
-       add     r1, r1, #20
+       add     r1, sp, #S_OFF + 20
+       sub     sp, sp, #4
        mov     r0, scno
        bl      __ipipe_syscall_root
        cmp     r0, #0
+       add     sp, sp, #4
        ldmfd   sp!, {r0-r3, ip}
        blt     __ipipe_ret_fast_syscall
        bgt     __ipipe_fast_exit_syscall

Initialise local variable last_jiffy_time:

--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -199,7 +199,8 @@ static void __init pxa_timer_init(void)
        setup_irq(IRQ_OST0, &pxa_timer_irq);
        local_irq_save(flags);
        OIER = OIER_E0;         /* enable match on timer 0 to cause interrupts */
-       OSMR0 = OSCR + LATCH;   /* set initial match */
+       last_jiffy_time = OSCR; /* initialize last_jiffy_time */
+       OSMR0 = last_jiffy_time + LATCH; /* set initial match */
        local_irq_restore(flags);

        /*

The second change needs to be applied to ipipe-2.6.15-arm-1.5-08 as well.

Well, that's it. Thanks again.

--
Michael

Re: [Xenomai-help] Xenomai problems on pxa

[Gilles Chanteperdrix]

On Jan 17, 2008 2:02 PM, Bernhard Michael <michael.bernhard@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> > I tested it on another arm (without EABI, so I can not know if it
> > works), and there is at least no regression.
>
> I tested it too with the EABI toolchain and its working. Thank you
> Gilles for your help.
>
> To sum up, here are the necessary ipipe changes to get xenomai running
> on pxa (compiled with an EABI toolchain).
>
> Kernel: 2.6.20,
> Adeos/Ipipe patch: ipipe-2.6.20-arm-1.8-03
>
> Align the stack pointer to 8-byte boundary:
>
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -216,11 +216,12 @@ ENTRY(vector_swi)
>         stmdb   sp!, {r4, r5}                   @ push fifth and sixth args
>  #ifdef CONFIG_IPIPE
>         stmfd   sp!, {r0-r3, ip}
> -       add     r1, sp, #S_OFF
> -       add     r1, r1, #20
> +       add     r1, sp, #S_OFF + 20
> +       sub     sp, sp, #4
>         mov     r0, scno
>         bl      __ipipe_syscall_root
>         cmp     r0, #0
> +       add     sp, sp, #4
>         ldmfd   sp!, {r0-r3, ip}
>         blt     __ipipe_ret_fast_syscall
>         bgt     __ipipe_fast_exit_syscall
>
> Initialise local variable last_jiffy_time:
>
> --- a/arch/arm/mach-pxa/time.c
> +++ b/arch/arm/mach-pxa/time.c
> @@ -199,7 +199,8 @@ static void __init pxa_timer_init(void)
>         setup_irq(IRQ_OST0, &pxa_timer_irq);
>         local_irq_save(flags);
>         OIER = OIER_E0;         /* enable match on timer 0 to cause interrupts */
> -       OSMR0 = OSCR + LATCH;   /* set initial match */
> +       last_jiffy_time = OSCR; /* initialize last_jiffy_time */
> +       OSMR0 = last_jiffy_time + LATCH; /* set initial match */
>         local_irq_restore(flags);
>
>         /*
>
> The second change needs to be applied to ipipe-2.6.15-arm-1.5-08 as well.
>
> Well, that's it. Thanks again.

Will merge, thanks to you.

-- 
                                               Gilles Chanteperdrix