* [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
@ 2013-10-15 22:23 Charles Steinkuehler
2013-10-16 10:44 ` Gilles Chanteperdrix
2013-10-16 11:09 ` Gilles Chanteperdrix
0 siblings, 2 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-15 22:23 UTC (permalink / raw)
To: xenomai
There seems to be some minor issue with the Xenomai patches for the
BeagleBone 3.8.13 ARM target. Occasionally, the eMMC task will hang for
greater than 60 seconds, causing the kernel to kill it, which basically
brings down the system (root is on the eMMC device).
I was writing this off to bad SD cards, and indeed I did have a card
that exhibited these symptoms on an x86 Linux system that had no xenomai
patches at all. I pitched this card and didn't have any more consistent
problems, but it turns out the bug is fairly simple to 'tickle'. Just
boot the xenomai patched kernel and run:
grep "TestConfig" /usr -r
...after a while, the mmcqd task will hang. I have not yet had a
xenomai kernel survive this test, while a "stock" kernel has gotten
through the whole /usr directory multiple times without issue.
So...how do I go about debugging this problem? Will testing with
different xenomai kernel configuration options (which ones?) possibly
shed any light on what's going wrong?
I'm not totally out of my depth here (I design hardware, so the
lower-level the code the easier it is for me to understand), but I don't
really do a lot of Linux Kernel hacking. I'm muddling forward as best I
can, but any advice would be appreciated.
A typical "hung task" report follows:
> [ 200.279217] INFO: task mmcqd/1:73 blocked for more than 60 seconds.
> [ 200.285938] "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 200.294286] mmcqd/1 D c06976c8 0 73 2 0x00000000
> [ 200.301177] [<c06976c8>] (__schedule+0x5b8/0x774) from [<c0695834>] (schedule_timeout+0x1c/0x21c)
> [ 200.310609] [<c0695834>] (schedule_timeout+0x1c/0x21c) from [<c0697a50>] (wait_for_common+0x130/0x170)
> [ 200.320537] [<c0697a50>] (wait_for_common+0x130/0x170) from [<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74)
> [ 200.330791] [<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74) from [<c051d630>] (mmc_start_req+0x50/0x158)
> [ 200.340758] [<c051d630>] (mmc_start_req+0x50/0x158) from [<c0528bf0>] (mmc_blk_issue_rw_rq+0xa4/0x348)
> [ 200.350659] [<c0528bf0>] (mmc_blk_issue_rw_rq+0xa4/0x348) from [<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450)
> [ 200.360952] [<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450) from [<c05298cc>] (mmc_queue_thread+0xa0/0x104)
> [ 200.371017] [<c05298cc>] (mmc_queue_thread+0xa0/0x104) from [<c005a69c>] (kthread+0xa0/0xb0)
> [ 200.380013] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>] (ret_from_fork+0x18/0x38)
> [ 200.388616] Kernel panic - not syncing: hung_task: blocked tasks
> [ 200.395001] [<c00138dc>] (unwind_backtrace+0x0/0xe0) from [<c06905d0>] (panic+0x84/0x1e0)
> [ 200.403641] [<c06905d0>] (panic+0x84/0x1e0) from [<c00943d0>] (watchdog+0x1d4/0x234)
> [ 200.411843] [<c00943d0>] (watchdog+0x1d4/0x234) from [<c005a69c>] (kthread+0xa0/0xb0)
> [ 200.420115] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>] (ret_from_fork+0x18/0x38)
> [ 200.428645] drm_kms_helper: panic occurred, switching back to text console
> [ 200.435919] Rebooting in 5 seconds..
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131015/7ac57a7d/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-15 22:23 [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel Charles Steinkuehler
@ 2013-10-16 10:44 ` Gilles Chanteperdrix
2013-10-16 11:10 ` Charles Steinkuehler
2013-10-16 11:09 ` Gilles Chanteperdrix
1 sibling, 1 reply; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 10:44 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 12:23 AM, Charles Steinkuehler wrote:
> There seems to be some minor issue with the Xenomai patches for the
> BeagleBone 3.8.13 ARM target. Occasionally, the eMMC task will hang for
> greater than 60 seconds, causing the kernel to kill it, which basically
> brings down the system (root is on the eMMC device).
>
> I was writing this off to bad SD cards, and indeed I did have a card
> that exhibited these symptoms on an x86 Linux system that had no xenomai
> patches at all. I pitched this card and didn't have any more consistent
> problems, but it turns out the bug is fairly simple to 'tickle'. Just
> boot the xenomai patched kernel and run:
>
> grep "TestConfig" /usr -r
>
> ...after a while, the mmcqd task will hang. I have not yet had a
> xenomai kernel survive this test, while a "stock" kernel has gotten
> through the whole /usr directory multiple times without issue.
>
> So...how do I go about debugging this problem? Will testing with
> different xenomai kernel configuration options (which ones?) possibly
> shed any light on what's going wrong?
>
> I'm not totally out of my depth here (I design hardware, so the
> lower-level the code the easier it is for me to understand), but I don't
> really do a lot of Linux Kernel hacking. I'm muddling forward as best I
> can, but any advice would be appreciated.
It points to several possible problems. So, a question, do you get this
while a Xenomai task is running? Or on an otherwise idle system?
Second question: is the Linux timer system running correctly, for
instance does "sleep 10" sleeps a little bit before returning, or does
it fail to return too?
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-15 22:23 [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel Charles Steinkuehler
2013-10-16 10:44 ` Gilles Chanteperdrix
@ 2013-10-16 11:09 ` Gilles Chanteperdrix
2013-10-16 11:38 ` Charles Steinkuehler
1 sibling, 1 reply; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 11:09 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 12:23 AM, Charles Steinkuehler wrote:
> There seems to be some minor issue with the Xenomai patches for the
> BeagleBone 3.8.13 ARM target. Occasionally, the eMMC task will hang for
> greater than 60 seconds, causing the kernel to kill it, which basically
> brings down the system (root is on the eMMC device).
>
> I was writing this off to bad SD cards, and indeed I did have a card
> that exhibited these symptoms on an x86 Linux system that had no xenomai
> patches at all. I pitched this card and didn't have any more consistent
> problems, but it turns out the bug is fairly simple to 'tickle'. Just
> boot the xenomai patched kernel and run:
>
> grep "TestConfig" /usr -r
>
> ...after a while, the mmcqd task will hang. I have not yet had a
> xenomai kernel survive this test, while a "stock" kernel has gotten
> through the whole /usr directory multiple times without issue.
>
> So...how do I go about debugging this problem? Will testing with
> different xenomai kernel configuration options (which ones?) possibly
> shed any light on what's going wrong?
>
> I'm not totally out of my depth here (I design hardware, so the
> lower-level the code the easier it is for me to understand), but I don't
> really do a lot of Linux Kernel hacking. I'm muddling forward as best I
> can, but any advice would be appreciated.
Could you attach:
- the full boot logs
- the kernel configuration
- the result of cat /proc/interrupts, cat /proc/xenomai/irq, cat
/proc/timer_list, cat /proc/xenomai/timer
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 10:44 ` Gilles Chanteperdrix
@ 2013-10-16 11:10 ` Charles Steinkuehler
2013-10-16 11:13 ` Gilles Chanteperdrix
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 11:10 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 5:44 AM, Gilles Chanteperdrix wrote:
> It points to several possible problems. So, a question, do you get this
> while a Xenomai task is running? Or on an otherwise idle system?
> Second question: is the Linux timer system running correctly, for
> instance does "sleep 10" sleeps a little bit before returning, or does
> it fail to return too?
In the test case, the system is otherwise idle when this happens. It is
the large amount of "disk" I/O to the SD card that causes the mmcqd
process to hang. Also, the grep -r doesn't fail immediately. It runs
for a while, sometimes getting far enough it finds one or two of the
four matching files in /usr, then the mmcqd task hangs.
Other than this occasional glitch, the kernel and system work normally.
This is the same kernel I am using to run LinuxCNC and I've managed to
get through many overnight 8+ hour prints, and have had uptimes of
several weeks.
I suspect an occasional lost interrupt or maybe a race condition or
something specific to the AM335x MMC driver. Xenomai seems otherwise to
run perfectly well on this hardware.
Note that think I have been seeing this issue occasionally for as long
as I have been testing Xenomain on the BeagleBone. I mostly chalked it
up to a bad SD card I had, but it seems like there's a deeper issue
involved. What changed is I just recently got a report with the very
simple way to trigger the bug using the recursive grep.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/6546b01f/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 11:10 ` Charles Steinkuehler
@ 2013-10-16 11:13 ` Gilles Chanteperdrix
0 siblings, 0 replies; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 11:13 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 01:10 PM, Charles Steinkuehler wrote:
> On 10/16/2013 5:44 AM, Gilles Chanteperdrix wrote:
>> It points to several possible problems. So, a question, do you
>> get this while a Xenomai task is running? Or on an otherwise idle
>> system? Second question: is the Linux timer system running
>> correctly, for instance does "sleep 10" sleeps a little bit
>> before returning, or does it fail to return too?
>
> In the test case, the system is otherwise idle when this happens.
> It is the large amount of "disk" I/O to the SD card that causes the
> mmcqd process to hang. Also, the grep -r doesn't fail immediately.
> It runs for a while, sometimes getting far enough it finds one or
> two of the four matching files in /usr, then the mmcqd task hangs.
>
> Other than this occasional glitch, the kernel and system work
> normally. This is the same kernel I am using to run LinuxCNC and
> I've managed to get through many overnight 8+ hour prints, and have
> had uptimes of several weeks.
This proves that Xenomai timer works correctly, not Linux timer. Could
you do the simple "sleep 10" test to verify that Linux timer is
running correctly?
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 11:09 ` Gilles Chanteperdrix
@ 2013-10-16 11:38 ` Charles Steinkuehler
2013-10-16 11:50 ` Gilles Chanteperdrix
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 11:38 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 6:09 AM, Gilles Chanteperdrix wrote:
> Could you do the simple "sleep 10" test to verify that Linux timer
> is running correctly?
Yes, sleep 10 works fine. Other than the SD card problem (which is very
rare), the system is perfectly normal.
> Could you attach:
> - the full boot logs
> - the kernel configuration
> - the result of cat /proc/interrupts, cat /proc/xenomai/irq, cat
> /proc/timer_list, cat /proc/xenomai/timer
Attached. I didn't know if you wanted the serial boot log or dmesg, so
you get both.
Thanks!
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.8.13xenomai-bone28.config
Type: application/xml
Size: 111571 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/be70f372/attachment.wsdl>
-------------- next part --------------
/proc/interrupts
CPU0
23: 2 INTC tps65217
28: 40721 INTC edma
30: 0 INTC edma_error
34: 0 INTC musb-hdrc.0.auto
35: 135 INTC musb-hdrc.1.auto
46: 93 INTC 4819c000.i2c
52: 0 INTC tilcdc
56: 0 INTC 4a100000.ethernet
57: 446759 INTC 4a100000.ethernet
58: 474084 INTC 4a100000.ethernet
59: 0 INTC 4a100000.ethernet
80: 127110 INTC mmc0
83: 355974 INTC gp_timer
86: 11533 INTC 44e0b000.i2c
88: 717 INTC OMAP UART0
91: 0 INTC rtc0
92: 0 INTC rtc0
125: 0 INTC 53100000.sham
150: 0 GPIO mmc0
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
Err: 0
/proc/xenomai/irq
IRQ CPU0
83: 421623 [timer]
1031: 0 [sync]
1032: 0 [timer-ipi]
1033: 0 [reschedule]
1034: 0 [virtual]
1038: 0 [virtual]
/proc/timer_list
Timer List Version: v0.7
HRTIMER_MAX_CLOCK_BASES: 3
now at 32955712727773 nsecs
cpu: 0
clock 0:
.base: c0f4fa80
.index: 0
.resolution: 1 nsecs
.get_time: ktime_get
.offset: 0 nsecs
active timers:
#0: <c0f4fbd8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/0/0
# expires at 32955712890625-32955712890625 nsecs [in 162852 to 162852 nsecs]
#1: <c0f4fce8>, watchdog_timer_fn, S:01, hrtimer_start, watchdog/0/11
# expires at 32956031250000-32956031250000 nsecs [in 318522227 to 318522227 nsecs]
#2: <de037b60>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, rpcbind/1684
# expires at 32956241340218-32956271340212 nsecs [in 528612445 to 558612439 nsecs]
#3: <df053ad0>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, init/1
# expires at 32960479417315-32960484417308 nsecs [in 4766689542 to 4771689535 nsecs]
#4: <de009f30>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, cron/2282
# expires at 32999494346432-32999494396432 nsecs [in 43781618659 to 43781668659 nsecs]
#5: <de059ad0>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, dhclient/1614
# expires at 33160403632091-33160503632091 nsecs [in 204690904318 to 204790904318 nsecs]
#6: <df303ad0>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, udhcpd/2193
# expires at 36043507350479-36043607350479 nsecs [in 3087794622706 to 3087894622706 nsecs]
#7: <de761ad0>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, rsyslogd/2235
# expires at 101062268804800-101062368804800 nsecs [in 68106556077027 to 68106656077027 nsecs]
clock 1:
.base: c0f4fab8
.index: 1
.resolution: 1 nsecs
.get_time: ktime_get_real
.offset: 1381890062400101079 nsecs
active timers:
clock 2:
.base: c0f4faf0
.index: 2
.resolution: 1 nsecs
.get_time: ktime_get_boottime
.offset: 0 nsecs
active timers:
.expires_next : 32955714843750 nsecs
.hres_active : 1
.nr_events : 356959
.nr_retries : 119
.nr_hangs : 0
.max_hang_time : 0 nsecs
.nohz_mode : 2
.last_tick : 32955480468750 nsecs
.tick_stopped : 0
.idle_jiffies : 16719607
.idle_calls : 664372
.idle_sleeps : 202249
.idle_entrytime : 32955700797023 nsecs
.idle_waketime : 32955700797023 nsecs
.idle_exittime : 32955700961273 nsecs
.idle_sleeptime : 32595857054501 nsecs
.iowait_sleeptime: 88093707363 nsecs
.last_jiffies : 16719710
.next_jiffies : 16719920
.idle_expires : 32956093750000 nsecs
jiffies: 16719725
Tick Device: mode: 1
Broadcast device
Clock Event Device: <NULL>
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000
Tick Device: mode: 1
Per CPU device: 0
Clock Event Device: gp_timer
max_delta_ns: 178956970805
min_delta_ns: 1000
mult: 1
shift: 0
mode: 3
next_event: 32955714843750 nsecs
set_next_event: xnarch_next_htick_shot
set_mode: xnarch_switch_htick_mode
event_handler: hrtimer_interrupt
retries: 0
/proc/xenomai/timer
status=on+watchdog:setup=833:clock=791430284289:timerdev=gp_timer:clockdev=ipipe_tsc
-------------- next part --------------
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.8.13xenomai-bone28 (charles@dozer) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #1 SMP Tue Oct 15 17:38:18 CDT 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 130816
[ 0.000000] free_area_init_node: node 0, pgdat c0a5d340, node_mem_map c0b3f000
[ 0.000000] Normal zone: 1024 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 129792 pages, LIFO batch:31
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 11 pages/cpu @c0f4f000 s23552 r8192 d13312 u45056
[ 0.000000] pcpu-alloc: s23552 r8192 d13312 u45056 alloc=11*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONE-EMMC-2G vram=50M root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] allocated 1048576 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] Memory: 511MB = 511MB total
[ 0.000000] Memory: 503172k/503172k available, 21116k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0988bf4 (9731 kB)
[ 0.000000] .init : 0xc0989000 - 0xc09dac00 ( 327 kB)
[ 0.000000] .data : 0xc09dc000 - 0xc0a60300 ( 529 kB)
[ 0.000000] .bss : 0xc0a60300 - 0xc0b3e3c0 ( 889 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] I-pipe, 24.000 MHz clocksource
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Interrupt pipeline (release #3)
[ 0.000000] Console: colour dummy device 80x30
[ 0.001252] Calibrating delay loop... 363.67 BogoMIPS (lpj=354304)
[ 0.017389] pid_max: default: 32768 minimum: 301
[ 0.017665] Security Framework initialized
[ 0.017773] Mount-cache hash table entries: 512
[ 0.028594] Initializing cgroup subsys cpuacct
[ 0.028631] Initializing cgroup subsys memory
[ 0.028703] Initializing cgroup subsys blkio
[ 0.028860] CPU: Testing write buffer coherency: ok
[ 0.029557] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.029639] Setting up static identity map for 0x8069f7c8 - 0x8069f820
[ 0.031419] Brought up 1 CPUs
[ 0.031444] SMP: Total of 1 processors activated (363.67 BogoMIPS).
[ 0.033323] devtmpfs: initialized
[ 0.098821] pinctrl core: initialized pinctrl subsystem
[ 0.099065] rstctl core: initialized rstctl subsystem
[ 0.099723] regulator-dummy: no parameters
[ 0.100260] NET: Registered protocol family 16
[ 0.101244] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.111547] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 0.112349] platform 49000000.edma: alias fck already exists
[ 0.112382] platform 49000000.edma: alias fck already exists
[ 0.112408] platform 49000000.edma: alias fck already exists
[ 0.113682] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[ 0.113890] OMAP GPIO hardware version 0.1
[ 0.115453] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[ 0.116834] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[ 0.118281] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[ 0.118829] of_get_named_gpio_flags exited with status 52
[ 0.118858] gpio-rctrl rstctl.3: loaded OK
[ 0.124644] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.126941] cpsw.0: No hwaddr in dt. Using c8:a0:30:ab:38:d9 from efuse
[ 0.126976] cpsw.1: No hwaddr in dt. Using c8:a0:30:ab:38:db from efuse
[ 0.143595] bio: create slab <bio-0> at 0
[ 0.155997] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[ 0.156294] of_get_named_gpio_flags: can't parse gpios property
[ 0.156525] vmmcsd_fixed: 3300 mV
[ 0.159438] SCSI subsystem initialized
[ 0.159891] usbcore: registered new interface driver usbfs
[ 0.160082] usbcore: registered new interface driver hub
[ 0.160410] usbcore: registered new device driver usb
[ 0.162644] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 0.164371] input: tps65217_pwr_but as /devices/ocp.2/44e0b000.i2c/i2c-0/0-0024/input/input0
[ 0.166343] DCDC1: at 1500 mV
[ 0.167591] vdd_mpu: 925 <--> 1325 mV at 950 mV
[ 0.168861] vdd_core: 925 <--> 1150 mV at 1100 mV
[ 0.170108] LDO1: at 1800 mV
[ 0.171283] LDO2: at 3300 mV
[ 0.173423] LDO3: 1800 mV
[ 0.174689] LDO4: at 3300 mV
[ 0.175829] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[ 0.176665] omap_i2c 44e0b000.i2c: unable to select pin group
[ 0.177461] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
[ 0.180284] omap_i2c 4819c000.i2c: unable to select pin group
[ 0.180521] media: Linux media interface: v0.10
[ 0.180631] Linux video capture interface: v2.00
[ 0.180809] pps_core: LinuxPPS API ver. 1 registered
[ 0.180826] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.181783] Advanced Linux Sound Architecture Driver Initialized.
[ 0.182853] NetLabel: Initializing
[ 0.182874] NetLabel: domain hash size = 128
[ 0.182886] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.183011] NetLabel: unlabeled traffic allowed by default
[ 0.183695] Switching to clocksource ipipe_tsc
[ 0.241907] NET: Registered protocol family 2
[ 0.243135] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.243283] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
[ 0.243445] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.243552] TCP: reno registered
[ 0.243579] UDP hash table entries: 256 (order: 1, 12288 bytes)
[ 0.243625] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[ 0.244067] NET: Registered protocol family 1
[ 0.244830] RPC: Registered named UNIX socket transport module.
[ 0.244854] RPC: Registered udp transport module.
[ 0.244868] RPC: Registered tcp transport module.
[ 0.244881] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.245303] Trying to unpack rootfs image as initramfs...
[ 0.604265] Freeing initrd memory: 2904K
[ 0.605153] CPU PMU: probing PMU on CPU 0
[ 0.605189] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 0.605903] omap2_mbox_probe: platform not supported
[ 0.893644] I-pipe: head domain Xenomai registered.
[ 0.893692] Xenomai: hal/arm started.
[ 0.895558] Xenomai: scheduling class idle registered.
[ 0.895589] Xenomai: scheduling class rt registered.
[ 0.904035] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
[ 0.904053] Xenomai: debug mode enabled.
[ 0.904714] Xenomai: starting native API services.
[ 0.904737] Xenomai: starting POSIX services.
[ 0.904942] Xenomai: starting RTDM services.
[ 0.906381] VFS: Disk quotas dquot_6.5.2
[ 0.906778] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.908175] NFS: Registering the id_resolver key type
[ 0.908292] Key type id_resolver registered
[ 0.908309] Key type id_legacy registered
[ 0.908495] fuse init (API version 7.20)
[ 0.909372] Btrfs loaded
[ 0.909566] msgmni has been set to 988
[ 0.912943] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 0.912971] io scheduler noop registered
[ 0.912986] io scheduler deadline registered
[ 0.913033] io scheduler cfq registered (default)
[ 0.915100] tps65217-bl tps65217-bl: no platform data provided
[ 0.915146] tps65217-bl: probe of tps65217-bl failed with error -22
[ 0.916026] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.918890] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[ 0.919241] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[ 1.719625] console [ttyO0] enabled
[ 1.724586] [drm] Initialized drm 1.1.0 20060810
[ 1.743963] brd: module loaded
[ 1.754960] loop: module loaded
[ 1.758441] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.765750] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.773078] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.780369] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.787655] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.802083] bone-capemgr bone_capemgr.8: Baseboard: 'A335BNLT,0A5A,1613BBBK1157'
[ 1.809877] bone-capemgr bone_capemgr.8: compatible-baseboard=ti,beaglebone-black
[ 1.817759] bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONE-EMMC-2G
[ 1.826467] bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONELT-HDMI
[ 1.865475] bone-capemgr bone_capemgr.8: slot #0: No cape found
[ 1.902580] bone-capemgr bone_capemgr.8: slot #1: No cape found
[ 1.939690] bone-capemgr bone_capemgr.8: slot #2: No cape found
[ 1.970027] bone-capemgr bone_capemgr.8: bone: Invalid signature 'ffffffff' at slot 3
[ 1.978257] bone-capemgr bone_capemgr.8: slot #3: No cape found
[ 1.984520] bone-capemgr bone_capemgr.8: slot #4: specific override
[ 1.991139] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
[ 1.999182] bone-capemgr bone_capemgr.8: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[ 2.009626] bone-capemgr bone_capemgr.8: slot #5: specific override
[ 2.016287] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 5
[ 2.024340] bone-capemgr bone_capemgr.8: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[ 2.034387] bone-capemgr bone_capemgr.8: slot #6: specific override
[ 2.041003] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 6
[ 2.049048] bone-capemgr bone_capemgr.8: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[ 2.059441] bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONE-EMMC-2G
[ 2.069125] bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 2.078917] bone-capemgr bone_capemgr.8: initialized OK.
[ 2.084542] bone-capemgr bone_capemgr.8: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.093404] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.104286] OneNAND driver initializing
[ 2.109921] usbcore: registered new interface driver cdc_ether
[ 2.116179] usbcore: registered new interface driver rndis_host
[ 2.122502] bone-capemgr bone_capemgr.8: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.131397] usbcore: registered new interface driver cdc_ncm
[ 2.137393] bone-capemgr bone_capemgr.8: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'
[ 2.152654] usbcore: registered new interface driver cdc_acm
[ 2.158615] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 2.167006] Initializing USB Mass Storage driver...
[ 2.172182] bone-capemgr bone_capemgr.8: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
[ 2.183649] usbcore: registered new interface driver usb-storage
[ 2.189970] USB Mass Storage support registered.
[ 2.195201] bone-capemgr bone_capemgr.8: slot #6: #2 overlays
[ 2.203639] platform 4830e000.fb: alias fck already exists
[ 2.209672] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[ 2.216291] bone-capemgr bone_capemgr.8: slot #6: Applied #2 overlays.
[ 2.223173] bone-capemgr bone_capemgr.8: loader: done slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.232267] musb-hdrc musb-hdrc.0.auto: pdev->id = 0
[ 2.237531] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[ 2.246469] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 2.246492] musb-hdrc: MHDRC RTL version 2.0
[ 2.246507] musb-hdrc: setup fifo_mode 4
[ 2.246534] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 2.246687] musb-hdrc musb-hdrc.0.auto: *** mode=3
[ 2.251794] musb-hdrc musb-hdrc.0.auto: *** power=250
[ 2.257904] musb-hdrc musb-hdrc.1.auto: pdev->id = 1
[ 2.263206] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[ 2.272014] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 2.272034] musb-hdrc: MHDRC RTL version 2.0
[ 2.272047] musb-hdrc: setup fifo_mode 4
[ 2.272068] musb-hdrc: 28/31 max ep, 16384/16384 memory
[ 2.272217] musb-hdrc musb-hdrc.1.auto: *** mode=1
[ 2.277322] musb-hdrc musb-hdrc.1.auto: *** power=250
[ 2.282661] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 2.289136] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[ 2.297455] musb-hdrc musb-hdrc.1.auto: supports USB remote wakeup
[ 2.297599] usb usb1: default language 0x0409
[ 2.297665] usb usb1: udev 1, busnum 1, minor = 0
[ 2.297687] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.304891] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.312476] usb usb1: Product: MUSB HDRC host driver
[ 2.317703] usb usb1: Manufacturer: Linux 3.8.13xenomai-bone28 musb-hcd
[ 2.324648] usb usb1: SerialNumber: musb-hdrc.1.auto
[ 2.330744] usb usb1: usb_probe_device
[ 2.330772] usb usb1: configuration #1 chosen from 1 choice
[ 2.330849] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 2.331052] hub 1-0:1.0: usb_probe_interface
[ 2.331074] hub 1-0:1.0: usb_probe_interface - got id
[ 2.331104] hub 1-0:1.0: USB hub found
[ 2.335151] hub 1-0:1.0: 1 port detected
[ 2.339303] hub 1-0:1.0: standalone hub
[ 2.339323] hub 1-0:1.0: individual port power switching
[ 2.339342] hub 1-0:1.0: no over-current protection
[ 2.339358] hub 1-0:1.0: Single TT
[ 2.339378] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
[ 2.339397] hub 1-0:1.0: power on to power good time: 10ms
[ 2.339445] hub 1-0:1.0: local power source is good
[ 2.339556] hub 1-0:1.0: enabling power on all ports
[ 2.340816] mousedev: PS/2 mouse device common for all mice
[ 2.349460] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 2.357012] 44e3e000.rtc: already running
[ 2.361596] i2c /dev entries driver
[ 2.367122] pps_ldisc: PPS line discipline registered
[ 2.372624] Driver for 1-wire Dallas network protocol.
[ 2.380177] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 2.388249] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[ 2.397654] of_get_named_gpio_flags exited with status 6
[ 2.397675] of_get_named_gpio_flags: can't parse gpios property
[ 2.397691] of_get_named_gpio_flags: can't parse gpios property
[ 2.397726] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed
[ 2.404996] omap_hsmmc mmc.4: Failed to get rstctl; not using any
[ 2.411894] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
[ 2.419143] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
[ 2.426533] mmc.4 supply vmmc_aux not found, using dummy regulator
[ 2.433573] omap_hsmmc mmc.4: pins are not configured from the driver
[ 2.440534] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 2.440617] hub 1-0:1.0: hub_suspend
[ 2.440662] usb usb1: bus auto-suspend, wakeup 1
[ 2.467709] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.7
[ 2.479468] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.7) status -22
[ 2.486782] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[ 2.495788] leds-gpio gpio-leds.7: pins are not configured from the driver
[ 2.503047] of_get_named_gpio_flags exited with status 53
[ 2.503071] of_get_named_gpio_flags exited with status 54
[ 2.503092] of_get_named_gpio_flags exited with status 55
[ 2.503111] of_get_named_gpio_flags exited with status 56
[ 2.503136] of_get_named_gpio_flags exited with status 53
[ 2.503485] of_get_named_gpio_flags exited with status 54
[ 2.503721] of_get_named_gpio_flags exited with status 55
[ 2.503922] of_get_named_gpio_flags exited with status 56
[ 2.504621] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.511509] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
[ 2.518805] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[ 2.527829] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[ 2.534179] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
[ 2.541461] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
[ 2.548668] usb usb1: usb wakeup-resume
[ 2.548720] usb usb1: usb auto-resume
[ 2.548751] hub 1-0:1.0: hub_resume
[ 2.548811] hub 1-0:1.0: port 1: status 0101 change 0001
[ 2.550498] usbcore: registered new interface driver usbhid
[ 2.556441] usbhid: USB HID core driver
[ 2.562056] ashmem: initialized
[ 2.566034] logger: created 256K log 'log_main'
[ 2.571354] logger: created 256K log 'log_events'
[ 2.576805] logger: created 256K log 'log_radio'
[ 2.582082] logger: created 256K log 'log_system'
[ 2.590702] TCP: cubic registered
[ 2.594419] NET: Registered protocol family 10
[ 2.600827] NET: Registered protocol family 17
[ 2.605973] Key type dns_resolver registered
[ 2.610879] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 2.619088] ThumbEE CPU extension supported.
[ 2.623652] Registering SWP/SWPB emulation handler
[ 2.630058] registered taskstats version 1
[ 2.637629] of_get_named_gpio_flags: can't parse gpios property
[ 2.637665] tilcdc 4830e000.fb: No power control GPIO
[ 2.645056] mmc0: host does not support reading read-only switch. assuming write-enable.
[ 2.653744] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000
[ 2.653818] hub 1-0:1.0: port 1, status 0101, change 0000, 12 Mb/s
[ 2.662810] mmc0: new high speed SDHC card at address aaaa
[ 2.672561] mmcblk0: mmc0:aaaa SU16G 14.8 GiB
[ 2.680100] mmcblk0: p1 p2
[ 2.758107] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 2.779053] tilcdc 4830e000.fb: found TDA19988
[ 2.784549] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 2.791544] [drm] No driver support for vblank timestamp query.
[ 2.883054] usb 1-1: ep0 maxpacket = 8
[ 2.884555] usb 1-1: skipped 1 descriptor after interface
[ 2.884574] usb 1-1: skipped 1 descriptor after interface
[ 2.884586] usb 1-1: skipped 1 descriptor after interface
[ 2.884778] usb 1-1: default language 0x0409
[ 2.885424] usb 1-1: udev 2, busnum 1, minor = 1
[ 2.885441] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
[ 2.885454] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.885466] usb 1-1: Product: USB Receiver
[ 2.885476] usb 1-1: Manufacturer: Logitech
[ 2.886145] usb 1-1: usb_probe_device
[ 2.886163] usb 1-1: configuration #1 chosen from 1 choice
[ 2.886933] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 2.887240] usbhid 1-1:1.0: usb_probe_interface
[ 2.887252] usbhid 1-1:1.0: usb_probe_interface - got id
[ 2.888517] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
[ 2.888758] usbhid 1-1:1.1: usb_probe_interface
[ 2.888770] usbhid 1-1:1.1: usb_probe_interface - got id
[ 2.891005] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
[ 2.891263] usbhid 1-1:1.2: usb_probe_interface
[ 2.891275] usbhid 1-1:1.2: usb_probe_interface - got id
[ 2.893297] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 2.893341] hub 1-0:1.0: port 1 enable change, status 00000103
[ 2.904693] tilcdc 4830e000.fb: Connected to an HDMI monitor with cea mode 2
[ 2.933295] Console: switching to colour frame buffer device 160x45
[ 2.981580] tilcdc 4830e000.fb: fb0: frame buffer device
[ 2.987258] tilcdc 4830e000.fb: registered panic notifier
[ 2.992961] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
[ 3.049079] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 3.055523] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 3.073583] libphy: 4a101000.mdio: probed
[ 3.077927] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 3.087831] Detected MACID = c8:a0:30:ab:38:d9
[ 3.092587] cpsw 4a100000.ethernet: NAPI disabled
[ 3.100071] omap_rtc 44e3e000.rtc: setting system clock to 2013-10-16 02:21:05 UTC (1381890065)
[ 3.116495] ALSA device list:
[ 3.119706] No soundcards found.
[ 3.124665] Freeing init memory: 324K
[ 3.265596] udevd[96]: starting version 175
[ 5.537490] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 5.545195] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 6.364659] EXT4-fs (mmcblk0p2): recovery complete
[ 6.374429] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 8.957945] udevd[321]: starting version 175
[ 10.798553] logitech-djreceiver 0003:046D:C52B.0003: hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-musb-hdrc.1.auto-1/input2
[ 10.899738] input: Logitech Unifying Device. Wireless PID:4024 as /devices/ocp.2/47400000.usb/musb-hdrc.1.auto/usb1/1-1/1-1:1.2/0003:046D:C52B.0003/input/input1
[ 10.935193] logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:4024] on usb-musb-hdrc.1.auto-1:1
[ 15.448101] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 15.905919] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
[ 21.137802] Adding 524284k swap on /mnt/SWAP.swap. Priority:-1 extents:2 across:532476k SS
[ 24.980401] net eth0: initializing cpsw version 1.12 (0)
[ 24.988596] net eth0: phy found : id is : 0x7c0f1
[ 24.993573] libphy: PHY 4a101000.mdio:01 not found
[ 24.998625] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 25.012047] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 28.067216] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 28.073297] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 35.827611] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 39.810472] gadget: using random self ethernet address
[ 39.854824] usb0: MAC 0e:1f:3e:5e:6e:37
[ 39.859026] usb0: HOST MAC c8:a0:30:ab:38:db
[ 39.935024] gadget: Mass Storage Function, version: 2009/09/11
[ 39.941369] gadget: Number of LUNs=1
[ 40.025514] lun0: LUN: removable file: /dev/mmcblk0p1
[ 40.080551] gadget: Multifunction Composite Gadget
[ 40.155598] gadget: g_multi ready
[ 40.200076] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[ 40.240663] musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 2
[ 40.283669] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
[ 40.283820] usb usb2: default language 0x0409
[ 40.283886] usb usb2: udev 1, busnum 2, minor = 128
[ 40.283911] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 40.291249] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 40.298841] usb usb2: Product: MUSB HDRC host driver
[ 40.304101] usb usb2: Manufacturer: Linux 3.8.13xenomai-bone28 musb-hcd
[ 40.311060] usb usb2: SerialNumber: musb-hdrc.0.auto
[ 40.354884] usb usb2: usb_probe_device
[ 40.354926] usb usb2: configuration #1 chosen from 1 choice
[ 40.355031] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[ 40.355357] hub 2-0:1.0: usb_probe_interface
[ 40.355382] hub 2-0:1.0: usb_probe_interface - got id
[ 40.355418] hub 2-0:1.0: USB hub found
[ 40.403436] hub 2-0:1.0: 1 port detected
[ 40.434074] hub 2-0:1.0: standalone hub
[ 40.434114] hub 2-0:1.0: individual port power switching
[ 40.434133] hub 2-0:1.0: no over-current protection
[ 40.434151] hub 2-0:1.0: Single TT
[ 40.434173] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns)
[ 40.434192] hub 2-0:1.0: power on to power good time: 10ms
[ 40.434271] hub 2-0:1.0: local power source is good
[ 40.434435] hub 2-0:1.0: enabling power on all ports
[ 40.535755] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[ 40.535859] hub 2-0:1.0: hub_suspend
[ 40.535907] usb usb2: bus auto-suspend, wakeup 1
[ 41.031661] tilcdc 4830e000.fb: timeout waiting for framedone
[ 42.950129] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 42.980609] NFSD: starting 90-second grace period (net c0a55800)
[ 43.030134] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[ 984.605736] tilcdc 4830e000.fb: timeout waiting for framedone
-------------- next part --------------
U-Boot SPL 2013.04-dirty (Jun 19 2013 - 09:57:14)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-dirty (Jun 19 2013 - 09:57:14)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
1710 bytes read in 5 ms (334 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading zImage
3479392 bytes read in 405 ms (8.2 MiB/s)
reading uInitrd
2975910 bytes read in 343 ms (8.3 MiB/s)
reading /dtbs/am335x-boneblack.dtb
24808 bytes read in 10 ms (2.4 MiB/s)
## Loading init Ramdisk from Legacy Image at 81000000 ...
Image Name: initramfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 2975846 Bytes = 2.8 MiB
Load Address: 00000000
Entry Point: 00000000
## Flattened Device Tree blob at 815f0000
Booting using the fdt blob at 0x815f0000
Using Device Tree in place at 815f0000, end 815f90e7
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.8.13xenomai-bone28 (charles@dozer) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #1 SMP Tue Oct 15 17:38:18 CDT 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 11 pages/cpu @c0f4f000 s23552 r8192 d13312 u45056
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONE-EMMC-2G vram=50M root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] allocated 1048576 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] Memory: 511MB = 511MB total
[ 0.000000] Memory: 503172k/503172k available, 21116k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0988bf4 (9731 kB)
[ 0.000000] .init : 0xc0989000 - 0xc09dac00 ( 327 kB)
[ 0.000000] .data : 0xc09dc000 - 0xc0a60300 ( 529 kB)
[ 0.000000] .bss : 0xc0a60300 - 0xc0b3e3c0 ( 889 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] I-pipe, 24.000 MHz clocksource
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Interrupt pipeline (release #3)
[ 0.000000] Console: colour dummy device 80x30
[ 0.001252] Calibrating delay loop... 363.67 BogoMIPS (lpj=354304)
[ 0.017389] pid_max: default: 32768 minimum: 301
[ 0.017665] Security Framework initialized
[ 0.017773] Mount-cache hash table entries: 512
[ 0.028594] Initializing cgroup subsys cpuacct
[ 0.028631] Initializing cgroup subsys memory
[ 0.028703] Initializing cgroup subsys blkio
[ 0.028860] CPU: Testing write buffer coherency: ok
[ 0.029557] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.029639] Setting up static identity map for 0x8069f7c8 - 0x8069f820
[ 0.031419] Brought up 1 CPUs
[ 0.031444] SMP: Total of 1 processors activated (363.67 BogoMIPS).
[ 0.033323] devtmpfs: initialized
[ 0.098821] pinctrl core: initialized pinctrl subsystem
[ 0.099065] rstctl core: initialized rstctl subsystem
[ 0.099723] regulator-dummy: no parameters
[ 0.100260] NET: Registered protocol family 16
[ 0.101244] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.111547] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 0.112349] platform 49000000.edma: alias fck already exists
[ 0.112382] platform 49000000.edma: alias fck already exists
[ 0.112408] platform 49000000.edma: alias fck already exists
[ 0.113890] OMAP GPIO hardware version 0.1
[ 0.118858] gpio-rctrl rstctl.3: loaded OK
[ 0.124644] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.126941] cpsw.0: No hwaddr in dt. Using c8:a0:30:ab:38:d9 from efuse
[ 0.126976] cpsw.1: No hwaddr in dt. Using c8:a0:30:ab:38:db from efuse
[ 0.143595] bio: create slab <bio-0> at 0
[ 0.155997] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[ 0.156525] vmmcsd_fixed: 3300 mV
[ 0.159438] SCSI subsystem initialized
[ 0.159891] usbcore: registered new interface driver usbfs
[ 0.160082] usbcore: registered new interface driver hub
[ 0.160410] usbcore: registered new device driver usb
[ 0.162644] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 0.164371] input: tps65217_pwr_but as /devices/ocp.2/44e0b000.i2c/i2c-0/0-0024/input/input0
[ 0.166343] DCDC1: at 1500 mV
[ 0.167591] vdd_mpu: 925 <--> 1325 mV at 950 mV
[ 0.168861] vdd_core: 925 <--> 1150 mV at 1100 mV
[ 0.170108] LDO1: at 1800 mV
[ 0.171283] LDO2: at 3300 mV
[ 0.173423] LDO3: 1800 mV
[ 0.174689] LDO4: at 3300 mV
[ 0.175829] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[ 0.176665] omap_i2c 44e0b000.i2c: unable to select pin group
[ 0.177461] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
[ 0.180284] omap_i2c 4819c000.i2c: unable to select pin group
[ 0.180521] media: Linux media interface: v0.10
[ 0.180631] Linux video capture interface: v2.00
[ 0.180809] pps_core: LinuxPPS API ver. 1 registered
[ 0.180826] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.181783] Advanced Linux Sound Architecture Driver Initialized.
[ 0.182853] NetLabel: Initializing
[ 0.182874] NetLabel: domain hash size = 128
[ 0.182886] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.183011] NetLabel: unlabeled traffic allowed by default
[ 0.183695] Switching to clocksource ipipe_tsc
[ 0.241907] NET: Registered protocol family 2
[ 0.243135] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.243283] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
[ 0.243445] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.243552] TCP: reno registered
[ 0.243579] UDP hash table entries: 256 (order: 1, 12288 bytes)
[ 0.243625] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[ 0.244067] NET: Registered protocol family 1
[ 0.244830] RPC: Registered named UNIX socket transport module.
[ 0.244854] RPC: Registered udp transport module.
[ 0.244868] RPC: Registered tcp transport module.
[ 0.244881] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.245303] Trying to unpack rootfs image as initramfs...
[ 0.604265] Freeing initrd memory: 2904K
[ 0.605153] CPU PMU: probing PMU on CPU 0
[ 0.605189] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 0.605903] omap2_mbox_probe: platform not supported
[ 0.893644] I-pipe: head domain Xenomai registered.
[ 0.893692] Xenomai: hal/arm started.
[ 0.895558] Xenomai: scheduling class idle registered.
[ 0.895589] Xenomai: scheduling class rt registered.
[ 0.904035] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
[ 0.904053] Xenomai: debug mode enabled.
[ 0.904714] Xenomai: starting native API services.
[ 0.904737] Xenomai: starting POSIX services.
[ 0.904942] Xenomai: starting RTDM services.
[ 0.906381] VFS: Disk quotas dquot_6.5.2
[ 0.906778] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.908175] NFS: Registering the id_resolver key type
[ 0.908292] Key type id_resolver registered
[ 0.908309] Key type id_legacy registered
[ 0.908495] fuse init (API version 7.20)
[ 0.909372] Btrfs loaded
[ 0.909566] msgmni has been set to 988
[ 0.912943] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 0.912971] io scheduler noop registered
[ 0.912986] io scheduler deadline registered
[ 0.913033] io scheduler cfq registered (default)
[ 0.915100] tps65217-bl tps65217-bl: no platform data provided
[ 0.915146] tps65217-bl: probe of tps65217-bl failed with error -22
[ 0.916026] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.918890] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[ 0.919241] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[ 1.719625] console [ttyO0] enabled
[ 1.724586] [drm] Initialized drm 1.1.0 20060810
[ 1.743963] brd: module loaded
[ 1.754960] loop: module loaded
[ 1.758441] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.765750] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.773078] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.780369] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.787655] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[ 1.802083] bone-capemgr bone_capemgr.8: Baseboard: 'A335BNLT,0A5A,1613BBBK1157'
[ 1.809877] bone-capemgr bone_capemgr.8: compatible-baseboard=ti,beaglebone-black
[ 1.817759] bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONE-EMMC-2G
[ 1.826467] bone-capemgr bone_capemgr.8: Skipping disabled cape with part# BB-BONELT-HDMI
[ 1.865475] bone-capemgr bone_capemgr.8: slot #0: No cape found
[ 1.902580] bone-capemgr bone_capemgr.8: slot #1: No cape found
[ 1.939690] bone-capemgr bone_capemgr.8: slot #2: No cape found
[ 1.970027] bone-capemgr bone_capemgr.8: bone: Invalid signature 'ffffffff' at slot 3
[ 1.978257] bone-capemgr bone_capemgr.8: slot #3: No cape found
[ 1.984520] bone-capemgr bone_capemgr.8: slot #4: specific override
[ 1.991139] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
[ 1.999182] bone-capemgr bone_capemgr.8: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[ 2.009626] bone-capemgr bone_capemgr.8: slot #5: specific override
[ 2.016287] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 5
[ 2.024340] bone-capemgr bone_capemgr.8: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[ 2.034387] bone-capemgr bone_capemgr.8: slot #6: specific override
[ 2.041003] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 6
[ 2.049048] bone-capemgr bone_capemgr.8: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[ 2.059441] bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONE-EMMC-2G
[ 2.069125] bone-capemgr bone_capemgr.8: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 2.078917] bone-capemgr bone_capemgr.8: initialized OK.
[ 2.084542] bone-capemgr bone_capemgr.8: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.093404] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.104286] OneNAND driver initializing
[ 2.109921] usbcore: registered new interface driver cdc_ether
[ 2.116179] usbcore: registered new interface driver rndis_host
[ 2.122502] bone-capemgr bone_capemgr.8: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.131397] usbcore: registered new interface driver cdc_ncm
[ 2.137393] bone-capemgr bone_capemgr.8: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'
[ 2.152654] usbcore: registered new interface driver cdc_acm
[ 2.158615] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 2.167006] Initializing USB Mass Storage driver...
[ 2.172182] bone-capemgr bone_capemgr.8: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
[ 2.183649] usbcore: registered new interface driver usb-storage
[ 2.189970] USB Mass Storage support registered.
[ 2.195201] bone-capemgr bone_capemgr.8: slot #6: #2 overlays
[ 2.203639] platform 4830e000.fb: alias fck already exists
[ 2.209672] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[ 2.216291] bone-capemgr bone_capemgr.8: slot #6: Applied #2 overlays.
[ 2.223173] bone-capemgr bone_capemgr.8: loader: done slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[ 2.232267] musb-hdrc musb-hdrc.0.auto: pdev->id = 0
[ 2.237531] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[ 2.246687] musb-hdrc musb-hdrc.0.auto: *** mode=3
[ 2.251794] musb-hdrc musb-hdrc.0.auto: *** power=250
[ 2.257904] musb-hdrc musb-hdrc.1.auto: pdev->id = 1
[ 2.263206] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[ 2.272217] musb-hdrc musb-hdrc.1.auto: *** mode=1
[ 2.277322] musb-hdrc musb-hdrc.1.auto: *** power=250
[ 2.282661] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 2.289136] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[ 2.297687] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.304891] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.312476] usb usb1: Product: MUSB HDRC host driver
[ 2.317703] usb usb1: Manufacturer: Linux 3.8.13xenomai-bone28 musb-hcd
[ 2.324648] usb usb1: SerialNumber: musb-hdrc.1.auto
[ 2.331104] hub 1-0:1.0: USB hub found
[ 2.335151] hub 1-0:1.0: 1 port detected
[ 2.340816] mousedev: PS/2 mouse device common for all mice
[ 2.349460] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 2.357012] 44e3e000.rtc: already running
[ 2.361596] i2c /dev entries driver
[ 2.367122] pps_ldisc: PPS line discipline registered
[ 2.372624] Driver for 1-wire Dallas network protocol.
[ 2.380177] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 2.388249] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[ 2.397726] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed
[ 2.404996] omap_hsmmc mmc.4: Failed to get rstctl; not using any
[ 2.411894] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
[ 2.419143] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
[ 2.426533] mmc.4 supply vmmc_aux not found, using dummy regulator
[ 2.433573] omap_hsmmc mmc.4: pins are not configured from the driver
[ 2.467709] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.7
[ 2.479468] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.7) status -22
[ 2.486782] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[ 2.495788] leds-gpio gpio-leds.7: pins are not configured from the driver
[ 2.504621] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.511509] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
[ 2.518805] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[ 2.527829] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[ 2.534179] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
[ 2.541461] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
[ 2.550498] usbcore: registered new interface driver usbhid
[ 2.556441] usbhid: USB HID core driver
[ 2.562056] ashmem: initialized
[ 2.566034] logger: created 256K log 'log_main'
[ 2.571354] logger: created 256K log 'log_events'
[ 2.576805] logger: created 256K log 'log_radio'
[ 2.582082] logger: created 256K log 'log_system'
[ 2.590702] TCP: cubic registered
[ 2.594419] NET: Registered protocol family 10
[ 2.600827] NET: Registered protocol family 17
[ 2.605973] Key type dns_resolver registered
[ 2.610879] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 2.619088] ThumbEE CPU extension supported.
[ 2.623652] Registering SWP/SWPB emulation handler
[ 2.630058] registered taskstats version 1
[ 2.637665] tilcdc 4830e000.fb: No power control GPIO
[ 2.645056] mmc0: host does not support reading read-only switch. assuming write-enable.
[ 2.662810] mmc0: new high speed SDHC card at address aaaa
[ 2.672561] mmcblk0: mmc0:aaaa SU16G 14.8 GiB
[ 2.680100] mmcblk0: p1 p2
[ 2.758107] usb 1-1: new full-speed USB device number 2 using musb-hdrc
[ 2.779053] tilcdc 4830e000.fb: found TDA19988
[ 2.784549] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 2.791544] [drm] No driver support for vblank timestamp query.
[ 2.885441] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
[ 2.885454] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.885466] usb 1-1: Product: USB Receiver
[ 2.885476] usb 1-1: Manufacturer: Logitech
[ 2.904693] tilcdc 4830e000.fb: Connected to an HDMI monitor with cea mode 2
[ 2.933295] Console: switching to colour frame buffer device 160x45
[ 2.981580] tilcdc 4830e000.fb: fb0: frame buffer device
[ 2.987258] tilcdc 4830e000.fb: registered panic notifier
[ 2.992961] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
[ 3.049079] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 3.055523] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 3.073583] libphy: 4a101000.mdio: probed
[ 3.077927] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 3.087831] Detected MACID = c8:a0:30:ab:38:d9
[ 3.092587] cpsw 4a100000.ethernet: NAPI disabled
[ 3.100071] omap_rtc 44e3e000.rtc: setting system clock to 2013-10-16 02:21:05 UTC (1381890065)
[ 3.116495] ALSA device list:
[ 3.119706] No soundcards found.
[ 3.124665] Freeing init memory: 324K
Loading, please wait...
[ 3.265596] udevd[96]: starting version 175
modprobe: chdir(3.8.13xenomai-bone28): No such file or directory
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... modprobe: chdir(3.8.13xenomai-bone28): No such file or directory
done.
modprobe: chdir(3.8.13xenomai-bone28): No such file or directory
[ 5.537490] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 5.545195] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 6.364659] EXT4-fs (mmcblk0p2): recovery complete
[ 6.374429] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
[....] Starting the hotplug events dispatcher: udevd[ 8.957945] udevd[321]: starting version 175
. ok
[ ok ] Synthesizing the initial hotplug events...done.
[....] Waiting for /dev to be fully populated...[ 10.798553] logitech-djreceiver 0003:046D:C52B.0003: hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-musb-hdrc.1.auto-1/input2
[ 10.899738] input: Logitech Unifying Device. Wireless PID:4024 as /devices/ocp.2/47400000.usb/musb-hdrc.1.auto/usb1/1-1/1-1:1.2/0003:046D:C52B.0003/input/input1
[ 10.935193] logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:4024] on usb-musb-hdrc.1.auto-1:1
done.
[ ok ] Setting preliminary keymap...done.
[ ok ] Setting parameters of disc: (none).
[ 15.448101] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[....] Checking root file system...fsck from util-linux 2.20.1
rootfs: clean, 162079/969136 files, 1091519/3872768 blocks
done.
[ 15.905919] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
[ ok ] Cleaning up temporary files... /tmp.
[....] Activating lvm and md swap...[ 21.137802] Adding 524284k swap on /mnt/SWAP.swap. Priority:-1 extents:2 across:532476k SS
done.
[....] Checking file systems...fsck from util-linux 2.20.1
done.
[ ok ] Mounting local filesystems...done.
[ ok ] Activating swapfile swap...done.
[ ok ] Cleaning up temporary files....
[ ok ] Setting kernel variables ...done.
[....] Configuring network interfaces...Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
[ 24.980401] net eth0: initializing cpsw version 1.12 (0)
[ 24.988596] net eth0: phy found : id is : 0x7c0f1
[ 24.993573] libphy: PHY 4a101000.mdio:01 not found
[ 24.998625] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 25.012047] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Listening on LPF/eth0/c8:a0:30:ab:38:d9
Sending on LPF/eth0/c8:a0:30:ab:38:d9
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
[ 28.067216] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 28.073297] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.34.1.20
DHCPACK from 10.34.1.20
bound to 10.34.1.71 -- renewal in 231 seconds.
done.
[ ok ] Starting rpcbind daemon....
[....] Starting NFS common utilities: statd[ 35.827611] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ ok pd.
[ ok ] Cleaning up temporary files....
[ ok ] Setting up ALSA...done.
[info] Setting console screen modes.
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device
[info] Skipping font and keymap setup (handled by console-setup).
[ ok ] Setting up console font and keymap...done.
[ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.
[ 39.810472] gadget: using random self ethernet address
[ 39.854824] usb0: MAC 0e:1f:3e:5e:6e:37
[ 39.859026] usb0: HOST MAC c8:a0:30:ab:38:db
[ 39.935024] gadget: Mass Storage Function, version: 2009/09/11
[ 39.941369] gadget: Number of LUNs=1
[ 40.025514] lun0: LUN: removable file: /dev/mmcblk0p1
[ 40.080551] gadget: Multifunction Composite Gadget
[ 40.155598] gadget: g_multi ready
[ 40.200076] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[ 40.240663] musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 2
[ 40.283911] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 40.291249] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 40.298841] usb usb2: Product: MUSB HDRC host driver
[ 40.304101] usb usb2: Manufacturer: Linux 3.8.13xenomai-bone28 musb-hcd
[ 40.311060] usb usb2: SerialNumber: musb-hdrc.0.auto
[ 40.355418] hub 2-0:1.0: USB hub found
[ 40.403436] hub 2-0:1.0: 1 port detected
[ ok ] Starting rpcbind daemon...[....] Already running..
[ ok ] Starting X display manager: xdm.
[ ok ] Starting NFS common utilities: statd idmapd[ 41.031661] tilcdc 4830e000.fb: timeout waiting for framedone
.
[ ok ] Exporting directories for NFS kernel daemon....
[....] Starting NFS kernel daemon: nfsd[ 42.950129] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 42.980609] NFSD: starting 90-second grace period (net c0a55800)
[ 43.030134] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[ ok td.
[ ok ] Starting enhanced syslogd: rsyslogd.
[ ok ] Starting periodic command scheduler: cron.
[ ok ] Starting system message bus: dbus.
saned disabled; edit /etc/default/saned
[ ok ] Loading cpufreq kernel modules...done (none).
[ ok ] Starting OpenBSD Secure Shell server: sshd.
[ ok ] CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, governor not available...done.
Starting very small Busybox based DHCP server: /usr/sbin/udhcpd already running.
udhcpd.
Debian GNU/Linux 7 arm ttyO0
arm login: [ 984.605736] tilcdc 4830e000.fb: timeout waiting for framedone
Debian GNU/Linux 7 arm ttyO0
arm login:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/be70f372/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 11:38 ` Charles Steinkuehler
@ 2013-10-16 11:50 ` Gilles Chanteperdrix
2013-10-16 12:08 ` Charles Steinkuehler
0 siblings, 1 reply; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 11:50 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 01:38 PM, Charles Steinkuehler wrote:
> On 10/16/2013 6:09 AM, Gilles Chanteperdrix wrote:
>> Could you do the simple "sleep 10" test to verify that Linux
>> timer is running correctly?
>
> Yes, sleep 10 works fine. Other than the SD card problem (which is
> very rare), the system is perfectly normal.
>
>> Could you attach: - the full boot logs - the kernel
>> configuration - the result of cat /proc/interrupts, cat
>> /proc/xenomai/irq, cat /proc/timer_list, cat /proc/xenomai/timer
>
> Attached. I didn't know if you wanted the serial boot log or
> dmesg, so you get both.
>
> Thanks!
>
Ok, so the MMC irq is a gpio irq. And its counter is 0, which does not
seem to be normal if the root filesystem in on MMC. Is it 0 too when
you boot an unpatched kernel?
Do you run a vanilla kernel or a vendor kernel with additional patches
to drivers/gpio/gpio-omap.c, or maybe a beaglebone specific GPIO
driver in drivers/gpio ?
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 11:50 ` Gilles Chanteperdrix
@ 2013-10-16 12:08 ` Charles Steinkuehler
2013-10-16 12:28 ` Charles Steinkuehler
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 12:08 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 6:50 AM, Gilles Chanteperdrix wrote:
> Ok, so the MMC irq is a gpio irq. And its counter is 0, which does not
> seem to be normal if the root filesystem in on MMC. Is it 0 too when
> you boot an unpatched kernel?
>
> Do you run a vanilla kernel or a vendor kernel with additional patches
> to drivers/gpio/gpio-omap.c, or maybe a beaglebone specific GPIO
> driver in drivers/gpio ?
It's a BeagleBone specific kernel with a list of patches as long as my
arm...and I have pretty long arms!
https://github.com/cdsteinkuehler/linux-dev/blob/3.8.13-bone28-xenomai/patch.sh
I'm not sure about the GPIO interrupt. I'll see what happens with the
non-xenomai kernel, and review the board setup.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/dbe5d383/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 12:08 ` Charles Steinkuehler
@ 2013-10-16 12:28 ` Charles Steinkuehler
2013-10-16 12:44 ` Gilles Chanteperdrix
2013-10-16 12:51 ` Ralf Roesch
0 siblings, 2 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 12:28 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 7:08 AM, Charles Steinkuehler wrote:
> On 10/16/2013 6:50 AM, Gilles Chanteperdrix wrote:
>> Ok, so the MMC irq is a gpio irq. And its counter is 0, which does not
>> seem to be normal if the root filesystem in on MMC. Is it 0 too when
>> you boot an unpatched kernel?
>>
>> Do you run a vanilla kernel or a vendor kernel with additional patches
>> to drivers/gpio/gpio-omap.c, or maybe a beaglebone specific GPIO
>> driver in drivers/gpio ?
>
> It's a BeagleBone specific kernel with a list of patches as long as my
> arm...and I have pretty long arms!
>
> https://github.com/cdsteinkuehler/linux-dev/blob/3.8.13-bone28-xenomai/patch.sh
>
> I'm not sure about the GPIO interrupt. I'll see what happens with the
> non-xenomai kernel, and review the board setup.
Both the BeagleBone and the Xenomai kernels behave the same way. The
GPIO mmc interrupt is stuck at zero, and the 80: INTC mmc interrupt
count increases on access to the filesystem.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/459dc82a/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 12:28 ` Charles Steinkuehler
@ 2013-10-16 12:44 ` Gilles Chanteperdrix
2013-10-16 12:52 ` Charles Steinkuehler
2013-10-16 12:51 ` Ralf Roesch
1 sibling, 1 reply; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 12:44 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 02:28 PM, Charles Steinkuehler wrote:
> On 10/16/2013 7:08 AM, Charles Steinkuehler wrote:
>> On 10/16/2013 6:50 AM, Gilles Chanteperdrix wrote:
>>> Ok, so the MMC irq is a gpio irq. And its counter is 0, which does not
>>> seem to be normal if the root filesystem in on MMC. Is it 0 too when
>>> you boot an unpatched kernel?
>>>
>>> Do you run a vanilla kernel or a vendor kernel with additional patches
>>> to drivers/gpio/gpio-omap.c, or maybe a beaglebone specific GPIO
>>> driver in drivers/gpio ?
>>
>> It's a BeagleBone specific kernel with a list of patches as long as my
>> arm...and I have pretty long arms!
>>
>> https://github.com/cdsteinkuehler/linux-dev/blob/3.8.13-bone28-xenomai/patch.sh
>>
>> I'm not sure about the GPIO interrupt. I'll see what happens with the
>> non-xenomai kernel, and review the board setup.
>
> Both the BeagleBone and the Xenomai kernels behave the same way. The
> GPIO mmc interrupt is stuck at zero, and the 80: INTC mmc interrupt
> count increases on access to the filesystem.
>
Maybe the GPIO interrupt is for the "Card detect signal", do you see it
increasing if you remove and re-insert the SD card?
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 12:28 ` Charles Steinkuehler
2013-10-16 12:44 ` Gilles Chanteperdrix
@ 2013-10-16 12:51 ` Ralf Roesch
1 sibling, 0 replies; 25+ messages in thread
From: Ralf Roesch @ 2013-10-16 12:51 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On Wed Oct 16 2013 14:28:21 GMT+0200, Charles Steinkuehler
<charles@steinkuehler.net> wrote:
> On 10/16/2013 7:08 AM, Charles Steinkuehler wrote:
>> On 10/16/2013 6:50 AM, Gilles Chanteperdrix wrote:
>>> Ok, so the MMC irq is a gpio irq. And its counter is 0, which does not
>>> seem to be normal if the root filesystem in on MMC. Is it 0 too when
>>> you boot an unpatched kernel?
>>>
>>> Do you run a vanilla kernel or a vendor kernel with additional patches
>>> to drivers/gpio/gpio-omap.c, or maybe a beaglebone specific GPIO
>>> driver in drivers/gpio ?
>> It's a BeagleBone specific kernel with a list of patches as long as my
>> arm...and I have pretty long arms!
>>
>> https://github.com/cdsteinkuehler/linux-dev/blob/3.8.13-bone28-xenomai/patch.sh
>>
>> I'm not sure about the GPIO interrupt. I'll see what happens with the
>> non-xenomai kernel, and review the board setup.
> Both the BeagleBone and the Xenomai kernels behave the same way. The
> GPIO mmc interrupt is stuck at zero, and the 80: INTC mmc interrupt
> count increases on access to the filesystem.
>
I have the same issue here (xenomai 3.8.13 bone28 patched kernel).
My file system works out from the BBB onboard flash. I have no SD card
in use, nor plugged in.
I assume that this mode has no card detect function.
MMC1 interrupts are increased on file system access.
root@arm:~# cat /proc/interrupts
CPU0
23: 2 INTC tps65217
28: 3633 INTC edma
30: 0 INTC edma_error
34: 0 INTC musb-hdrc.0.auto
35: 1 INTC musb-hdrc.1.auto
36: 0 INTC pruss_evt0
37: 0 INTC pruss_evt1
38: 0 INTC pruss_evt2
39: 0 INTC pruss_evt3
40: 0 INTC pruss_evt4
41: 0 INTC pruss_evt5
42: 0 INTC pruss_evt6
43: 0 INTC pruss_evt7
44: 12085 INTC mmc1
46: 96 INTC 4819c000.i2c
52: 0 INTC tilcdc
56: 0 INTC 4a100000.ethernet
57: 104628 INTC 4a100000.ethernet
58: 153 INTC 4a100000.ethernet
59: 0 INTC 4a100000.ethernet
80: 0 INTC mmc0
83: 477814 INTC gp_timer
86: 21786 INTC 44e0b000.i2c
88: 362463 INTC OMAP UART0
91: 0 INTC rtc0
92: 0 INTC rtc0
125: 0 INTC 53100000.sham
150: 0 GPIO mmc0
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
Err: 0
--
Ralf
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 12:44 ` Gilles Chanteperdrix
@ 2013-10-16 12:52 ` Charles Steinkuehler
2013-10-16 15:25 ` Charles Steinkuehler
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 12:52 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 7:44 AM, Gilles Chanteperdrix wrote:
> On 10/16/2013 02:28 PM, Charles Steinkuehler wrote:
>> Both the BeagleBone and the Xenomai kernels behave the same way. The
>> GPIO mmc interrupt is stuck at zero, and the 80: INTC mmc interrupt
>> count increases on access to the filesystem.
>>
> Maybe the GPIO interrupt is for the "Card detect signal", do you see it
> increasing if you remove and re-insert the SD card?
I can't really try that without totally killing the system, since I have
to run off the SD card. I do know that SD card detection and swapping
is essentially broken in the current BeagleBone kernels (you can use the
2G on-board eMMC or the SD Card socket, but not both at the same
time...for software driver reasons, not hardware).
Anyway, are there any in-between steps I can test with the kernel that
might help isolate what code to go over in the mmc driver? Anything
between "no xenomai patches" and "patched and configured to run xenomai"
might potentially be enlightening. IIRC there have been discussions
previously about disabling the ipipe patch and seeing if the kernel
still worked, but I couldn't turn up anything like that in the
troubleshooting guide and I'm not positive which configuration switches
are safe to mess with.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/a8b59aa4/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 12:52 ` Charles Steinkuehler
@ 2013-10-16 15:25 ` Charles Steinkuehler
2013-10-16 15:58 ` Gilles Chanteperdrix
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 15:25 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 7:52 AM, Charles Steinkuehler wrote:
> Anyway, are there any in-between steps I can test with the kernel that
> might help isolate what code to go over in the mmc driver? Anything
> between "no xenomai patches" and "patched and configured to run xenomai"
> might potentially be enlightening.
I built and tested a patched kernel that has no xenomai configure
options enabled:
# CONFIG_XEN is not set
...and I still get the hang.
I'll start reviewing the driver changes pre and post the xenomai
patches, but would appreciate any suggestions or guidance as to what I
should be looking for.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/ca4f0c7f/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 15:25 ` Charles Steinkuehler
@ 2013-10-16 15:58 ` Gilles Chanteperdrix
2013-10-16 16:12 ` Charles Steinkuehler
2013-10-16 18:12 ` Ralf Roesch
0 siblings, 2 replies; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-16 15:58 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/16/2013 05:25 PM, Charles Steinkuehler wrote:
> On 10/16/2013 7:52 AM, Charles Steinkuehler wrote:
>> Anyway, are there any in-between steps I can test with the kernel that
>> might help isolate what code to go over in the mmc driver? Anything
>> between "no xenomai patches" and "patched and configured to run xenomai"
>> might potentially be enlightening.
>
> I built and tested a patched kernel that has no xenomai configure
> options enabled:
>
> # CONFIG_XEN is not set
CONFIG_XEN is for Xen, not Xenomai. The interesting steps are:
- CONFIG_IPIPE enabled with CONFIG_XENOMAI disabled
- patched kernel with CONFIG_IPIPE off and CONFIG_XENOMAI off.
In addition to the troubleshooting guide, you may find the following
documentation useful:
https://www.xenomai.org/index.php/I-pipe-core:ArmPorting
If the issue is not a timer issue, and it does not seem to be, the most
probable explanation is that either the MMC driver or the interrupt
controller does not like receiving interrupts while they are masked. In
this case, you will find that the patched kernel does not work with
CONFIG_IPIPE but works with CONFIG_IPIPE off and CONFIG_XENOMAI off.
Do you know if the interrupt is level or edge triggered?
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 15:58 ` Gilles Chanteperdrix
@ 2013-10-16 16:12 ` Charles Steinkuehler
2013-10-16 19:41 ` Charles Steinkuehler
2013-10-16 18:12 ` Ralf Roesch
1 sibling, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 16:12 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 10:58 AM, Gilles Chanteperdrix wrote:
> On 10/16/2013 05:25 PM, Charles Steinkuehler wrote:
>> On 10/16/2013 7:52 AM, Charles Steinkuehler wrote:
>>> Anyway, are there any in-between steps I can test with the kernel that
>>> might help isolate what code to go over in the mmc driver? Anything
>>> between "no xenomai patches" and "patched and configured to run xenomai"
>>> might potentially be enlightening.
>>
>> I built and tested a patched kernel that has no xenomai configure
>> options enabled:
>>
>> # CONFIG_XEN is not set
Oops...too quick with the cut-and-paste. This is the configuration I
tested with that still fails.
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_IPIPE_ARM_KUSER_TSC=y
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_TARGET_APIREV=1
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_IPIPE_DEBUG is not set
# CONFIG_XENOMAI is not set
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
> CONFIG_XEN is for Xen, not Xenomai. The interesting steps are:
> - CONFIG_IPIPE enabled with CONFIG_XENOMAI disabled
> - patched kernel with CONFIG_IPIPE off and CONFIG_XENOMAI off.
So it looks like I tried the first option (ipipe enabled, xenomai
disabled, result = still broken), I'll try disabling ipipe as well and
see what happens.
> In addition to the troubleshooting guide, you may find the following
> documentation useful:
> https://www.xenomai.org/index.php/I-pipe-core:ArmPorting
Thanks!
> If the issue is not a timer issue, and it does not seem to be, the most
> probable explanation is that either the MMC driver or the interrupt
> controller does not like receiving interrupts while they are masked. In
> this case, you will find that the patched kernel does not work with
> CONFIG_IPIPE but works with CONFIG_IPIPE off and CONFIG_XENOMAI off.
> Do you know if the interrupt is level or edge triggered?
I don't know much detail yet, I'm still crawling around the driver code
and trying to make sense of things.
I'll test with ipipe disabled, go through the Arm Porting guide, and see
where that gets me...
Many thanks for all the help!
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/91700325/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 15:58 ` Gilles Chanteperdrix
2013-10-16 16:12 ` Charles Steinkuehler
@ 2013-10-16 18:12 ` Ralf Roesch
1 sibling, 0 replies; 25+ messages in thread
From: Ralf Roesch @ 2013-10-16 18:12 UTC (permalink / raw)
To: xenomai
On Wed Oct 16 2013 17:58:26 GMT+0200 (CEST), Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> If the issue is not a timer issue, and it does not seem to be, the
> most probable explanation is that either the MMC driver or the
> interrupt controller does not like receiving interrupts while they are
> masked. In this case, you will find that the patched kernel does not
> work with CONFIG_IPIPE but works with CONFIG_IPIPE off and
> CONFIG_XENOMAI off.
> Do you know if the interrupt is level or edge triggered?
>
> Regards.
>
>
The mmc interrupts are handled by INTC. I assume they are level triggered:
-> interrupt section of the AM335x technical reference manual (BBB is
based on AM3359):
--
The INTC supports only level-sensitive incoming interrupt detection. A
peripheral asserting an interrupt
maintains it until software has handled the interrupt and instructed the
peripheral to deassert the interrupt.
--
regards
Ralf
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 16:12 ` Charles Steinkuehler
@ 2013-10-16 19:41 ` Charles Steinkuehler
2013-10-17 0:58 ` Charles Steinkuehler
0 siblings, 1 reply; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-16 19:41 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
> I'll test with ipipe disabled, go through the Arm Porting guide, and see
> where that gets me...
After building a patched kernel without ipipe or xenomai enabled:
$ egrep '(IPIPE|XENO)' KERNEL/.config
# CONFIG_XENOMAI is not set
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
# CONFIG_IPIPE is not set
...the mmc issue seems fixed. So according to the porting guide, this
indicates a likely problem with interrupts or the interrupt controller
(as Gilles indicated).
Looks like I get to dive into IRQ code review...at least I have some
configuration options to grep for to hopefully light the way. And I
have a test case that kills the system in fairly short order!
Thanks again for all the help and hand-holding!
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/11455866/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-16 19:41 ` Charles Steinkuehler
@ 2013-10-17 0:58 ` Charles Steinkuehler
2013-10-17 2:21 ` Charles Steinkuehler
2013-10-17 9:29 ` Gilles Chanteperdrix
0 siblings, 2 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-17 0:58 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>> I'll test with ipipe disabled, go through the Arm Porting guide, and see
>> where that gets me...
>
> After building a patched kernel without ipipe or xenomai enabled:
>
> $ egrep '(IPIPE|XENO)' KERNEL/.config
> # CONFIG_XENOMAI is not set
> CONFIG_XENO_GENERIC_STACKPOOL=y
> CONFIG_XENO_FASTSYNCH_DEP=y
> CONFIG_XENO_FASTSYNCH=y
> # CONFIG_IPIPE is not set
>
> ...the mmc issue seems fixed. So according to the porting guide, this
> indicates a likely problem with interrupts or the interrupt controller
> (as Gilles indicated).
Based on the ARM porting guide, the first thing I did was to disable IRQ
muting by simply commenting out the two calls to:
ipipe_pic_muter_register
...in <linux>/drivers/gpio/gpio-omap.c
This results in a kernel that DOES NOT HANG with ipipe enabled!
So it looks like the issue is related to interrupt muting, and I have
two paths to push forward:
1) Build a kernel with ipipe and xenomai both enabled (but no IRQ
muting) and see if this works (and how much it affects worst-case latency)
2) Dig into the IRQ muting code and look for any goofs
I can handle #1, building and testing a kernel with IRQ muting disabled.
Can anyone advise on a good way to approach #2? Since everything
_almost_ works, I suspect a problem that could be difficult to find,
especially for someone like me who isn't really all that familiar with
the Linux kernel and ipipe internals.
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/330bf34d/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 0:58 ` Charles Steinkuehler
@ 2013-10-17 2:21 ` Charles Steinkuehler
2013-10-17 9:29 ` Gilles Chanteperdrix
1 sibling, 0 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-17 2:21 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/16/2013 7:58 PM, Charles Steinkuehler wrote:
> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>> I'll test with ipipe disabled, go through the Arm Porting guide, and see
>>> where that gets me...
>>
>> After building a patched kernel without ipipe or xenomai enabled:
>>
>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>> # CONFIG_XENOMAI is not set
>> CONFIG_XENO_GENERIC_STACKPOOL=y
>> CONFIG_XENO_FASTSYNCH_DEP=y
>> CONFIG_XENO_FASTSYNCH=y
>> # CONFIG_IPIPE is not set
>>
>> ...the mmc issue seems fixed. So according to the porting guide, this
>> indicates a likely problem with interrupts or the interrupt controller
>> (as Gilles indicated).
>
> Based on the ARM porting guide, the first thing I did was to disable IRQ
> muting by simply commenting out the two calls to:
>
> ipipe_pic_muter_register
>
> ...in <linux>/drivers/gpio/gpio-omap.c
>
> This results in a kernel that DOES NOT HANG with ipipe enabled!
>
> So it looks like the issue is related to interrupt muting, and I have
> two paths to push forward:
>
> 1) Build a kernel with ipipe and xenomai both enabled (but no IRQ
> muting) and see if this works (and how much it affects worst-case latency)
Sadly, enabling xenomai (but leaving the IRQ muting disabled) still
results in the hangs, so it's not quite so simple after all...
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131016/9b0b0baa/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 0:58 ` Charles Steinkuehler
2013-10-17 2:21 ` Charles Steinkuehler
@ 2013-10-17 9:29 ` Gilles Chanteperdrix
2013-10-17 10:24 ` Ralf Roesch
2013-10-17 12:39 ` Charles Steinkuehler
1 sibling, 2 replies; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-17 9:29 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>> I'll test with ipipe disabled, go through the Arm Porting guide, and see
>>> where that gets me...
>>
>> After building a patched kernel without ipipe or xenomai enabled:
>>
>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>> # CONFIG_XENOMAI is not set
>> CONFIG_XENO_GENERIC_STACKPOOL=y
>> CONFIG_XENO_FASTSYNCH_DEP=y
>> CONFIG_XENO_FASTSYNCH=y
>> # CONFIG_IPIPE is not set
>>
>> ...the mmc issue seems fixed. So according to the porting guide, this
>> indicates a likely problem with interrupts or the interrupt controller
>> (as Gilles indicated).
>
> Based on the ARM porting guide, the first thing I did was to disable IRQ
> muting by simply commenting out the two calls to:
>
> ipipe_pic_muter_register
>
> ...in <linux>/drivers/gpio/gpio-omap.c
>
> This results in a kernel that DOES NOT HANG with ipipe enabled!
It does not really make sense: when I-pipe is enabled but Xenomai
disabled, the PIC muting is only used to tweak the interrupt controller
priority. Since there are only secondary mode irqs, they all should use
the same priority.
Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if yes,
could you put the modified version somewhere I could have a look at it?
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 9:29 ` Gilles Chanteperdrix
@ 2013-10-17 10:24 ` Ralf Roesch
2013-10-17 12:39 ` Charles Steinkuehler
1 sibling, 0 replies; 25+ messages in thread
From: Ralf Roesch @ 2013-10-17 10:24 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu Oct 17 2013 11:29:30 GMT+0200, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
>> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>>> I'll test with ipipe disabled, go through the Arm Porting guide,
>>>> and see
>>>> where that gets me...
>>>
>>> After building a patched kernel without ipipe or xenomai enabled:
>>>
>>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>>> # CONFIG_XENOMAI is not set
>>> CONFIG_XENO_GENERIC_STACKPOOL=y
>>> CONFIG_XENO_FASTSYNCH_DEP=y
>>> CONFIG_XENO_FASTSYNCH=y
>>> # CONFIG_IPIPE is not set
>>>
>>> ...the mmc issue seems fixed. So according to the porting guide, this
>>> indicates a likely problem with interrupts or the interrupt controller
>>> (as Gilles indicated).
>>
>> Based on the ARM porting guide, the first thing I did was to disable IRQ
>> muting by simply commenting out the two calls to:
>>
>> ipipe_pic_muter_register
>>
>> ...in <linux>/drivers/gpio/gpio-omap.c
>>
>> This results in a kernel that DOES NOT HANG with ipipe enabled!
>
> It does not really make sense: when I-pipe is enabled but Xenomai
> disabled, the PIC muting is only used to tweak the interrupt
> controller priority. Since there are only secondary mode irqs, they
> all should use the same priority.
>
> Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if
> yes, could you put the modified version somewhere I could have a look
> at it?
>
> Regards.
>
I think following additional patch has been applied by the bone patch set:
From 931f9fa298dcbdddfc82f9227596a445fd174f17 Mon Sep 17 00:00:00 2001
From: =?utf8?q?H=C3=A5kan=20Engblom?= <hkengblom@gmail.com>
Date: Wed, 24 Apr 2013 10:53:46 +0200
Subject: [PATCH] omap2 irq: fix interrupt latency
The problem in my system was that interrutp latency for GPIO interrupts
(GPIO used as interrupt source by use of "echo rising >
/sys/class/gpio/gpioXX/edge") was _very_ long, probably until somother
interrupt made GPIO interrupts "visable". The problem that the patch
corrects is that also a AM33XX has four registers to check in the
interrupt controller to find out which interrupt that caused the
controlled to assert an interrupt.
---
arch/arm/mach-omap2/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 3926f37..57d1b7d 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -233,7 +233,7 @@ static inline void omap_intc_handle_irq(void __iomem
*base_addr, struct pt_regs
goto out;
irqnr = readl_relaxed(base_addr + 0xd8);
-#ifdef CONFIG_SOC_TI81XX
+#if defined(CONFIG_SOC_TI81XX) || defined(CONFIG_SOC_AM33XX)
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xf8);
--
1.8.4.rc3
(complete source attached)
regards
Ralf
-------------- next part --------------
/*
* linux/arch/arm/mach-omap2/irq.c
*
* Interrupt handler for OMAP2 boards.
*
* Copyright (C) 2005 Nokia Corporation
* Author: Paul Mundt <paul.mundt@nokia.com>
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <asm/ipipe.h>
#include <asm/exception.h>
#include <asm/mach/irq.h>
#include <linux/irqdomain.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include "soc.h"
#include "iomap.h"
#include "common.h"
/* selected INTC register offsets */
#define INTC_REVISION 0x0000
#define INTC_SYSCONFIG 0x0010
#define INTC_SYSSTATUS 0x0014
#define INTC_SIR 0x0040
#define INTC_CONTROL 0x0048
#define INTC_PROTECTION 0x004C
#define INTC_IDLE 0x0050
#define INTC_THRESHOLD 0x0068
#define INTC_MIR0 0x0084
#define INTC_MIR_CLEAR0 0x0088
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
#define INTC_PRIO 0x0100
/* Number of IRQ state bits in each MIR register */
#define IRQ_BITS_PER_REG 32
#define OMAP2_IRQ_BASE OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE)
#define OMAP3_IRQ_BASE OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE)
#define INTCPS_SIR_IRQ_OFFSET 0x0040 /* omap2/3 active interrupt offset */
#define ACTIVEIRQ_MASK 0x7f /* omap2/3 active interrupt bits */
#define INTCPS_NR_MIR_REGS 3
#define INTCPS_NR_IRQS 96
#if !defined(MULTI_OMAP1) && !defined(MULTI_OMAP2)
#define inline_single inline
#else
#define inline_single
#endif
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own "bank". Register definitions are
* fairly consistent for each bank, but not all registers are implemented
* for each bank.. when in doubt, consult the TRM.
*/
static struct omap_irq_bank {
void __iomem *base_reg;
unsigned int nr_irqs;
} __attribute__ ((aligned(4))) irq_banks[] = {
{
/* MPU INTC */
.nr_irqs = 96,
},
};
static struct irq_domain *domain;
/* Structure to save interrupt controller context */
struct omap3_intc_regs {
u32 sysconfig;
u32 protection;
u32 idle;
u32 threshold;
u32 ilr[INTCPS_NR_IRQS];
u32 mir[INTCPS_NR_MIR_REGS];
};
/* INTC bank register get/set */
static inline_single void intc_bank_write_reg(u32 val, struct omap_irq_bank *bank, u16 reg)
{
__raw_writel(val, bank->base_reg + reg);
}
static inline_single u32 intc_bank_read_reg(struct omap_irq_bank *bank, u16 reg)
{
return __raw_readl(bank->base_reg + reg);
}
/* XXX: FIQ and additional INTC support (only MPU at the moment) */
static inline_single void omap_ack_irq(struct irq_data *d)
{
intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
dsb();
}
static void omap_mask_ack_irq(struct irq_data *d)
{
irq_gc_mask_disable_reg(d);
omap_ack_irq(d);
}
static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
{
unsigned long tmp;
tmp = intc_bank_read_reg(bank, INTC_REVISION) & 0xff;
pr_info("IRQ: Found an INTC at 0x%p (revision %ld.%ld) with %d interrupts\n",
bank->base_reg, tmp >> 4, tmp & 0xf, bank->nr_irqs);
tmp = intc_bank_read_reg(bank, INTC_SYSCONFIG);
tmp |= 1 << 1; /* soft reset */
intc_bank_write_reg(tmp, bank, INTC_SYSCONFIG);
while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) & 0x1))
/* Wait for reset to complete */;
#ifndef CONFIG_IPIPE
/* Enable autoidle */
intc_bank_write_reg(1 << 0, bank, INTC_SYSCONFIG);
intc_bank_write_reg(0x2, bank, INTC_IDLE);
#else /* CONFIG_IPIPE */
/* Disable autoidle */
intc_bank_write_reg(0, bank, INTC_SYSCONFIG);
intc_bank_write_reg(0x1, bank, INTC_IDLE);
#endif /* CONFIG_IPIPE */
}
int omap_irq_pending(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
int irq;
for (irq = 0; irq < bank->nr_irqs; irq += 32)
if (intc_bank_read_reg(bank, INTC_PENDING_IRQ0 +
((irq >> 5) << 5)))
return 1;
}
return 0;
}
static __init void
omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num)
{
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
gc = irq_alloc_generic_chip("INTC", 1, irq_start, base,
handle_level_irq);
ct = gc->chip_types;
ct->chip.irq_ack = omap_mask_ack_irq;
ct->chip.irq_mask = irq_gc_mask_disable_reg;
#ifdef CONFIG_IPIPE
ct->chip.irq_mask_ack = omap_mask_ack_irq;
#endif
ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
ct->chip.flags |= IRQCHIP_SKIP_SET_WAKE;
ct->regs.enable = INTC_MIR_CLEAR0;
ct->regs.disable = INTC_MIR_SET0;
irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
static void __init omap_init_irq(u32 base, int nr_irqs,
struct device_node *node)
{
void __iomem *omap_irq_base;
unsigned long nr_of_irqs = 0;
unsigned int nr_banks = 0;
int i, j, irq_base;
omap_irq_base = ioremap(base, SZ_4K);
if (WARN_ON(!omap_irq_base))
return;
irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
if (irq_base < 0) {
pr_warn("Couldn't allocate IRQ numbers\n");
irq_base = 0;
}
domain = irq_domain_add_legacy(node, nr_irqs, irq_base, 0,
&irq_domain_simple_ops, NULL);
for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
bank->nr_irqs = nr_irqs;
/* Static mapping, never released */
bank->base_reg = ioremap(base, SZ_4K);
if (!bank->base_reg) {
pr_err("Could not ioremap irq bank%i\n", i);
continue;
}
omap_irq_bank_init_one(bank);
for (j = 0; j < bank->nr_irqs; j += 32)
omap_alloc_gc(bank->base_reg + j, j + irq_base, 32);
nr_of_irqs += bank->nr_irqs;
nr_banks++;
}
pr_info("Total of %ld interrupts on %d active controller%s\n",
nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
}
void __init omap2_init_irq(void)
{
omap_init_irq(OMAP24XX_IC_BASE, 96, NULL);
}
void __init omap3_init_irq(void)
{
omap_init_irq(OMAP34XX_IC_BASE, 96, NULL);
}
void __init ti81xx_init_irq(void)
{
omap_init_irq(OMAP34XX_IC_BASE, 128, NULL);
}
static inline void omap_intc_handle_irq(void __iomem *base_addr, struct pt_regs *regs)
{
u32 irqnr;
do {
irqnr = readl_relaxed(base_addr + 0x98);
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xb8);
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xd8);
#if defined(CONFIG_SOC_TI81XX) || defined(CONFIG_SOC_AM33XX)
if (irqnr)
goto out;
irqnr = readl_relaxed(base_addr + 0xf8);
#endif
out:
if (!irqnr)
break;
irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
irqnr &= ACTIVEIRQ_MASK;
if (irqnr) {
irqnr = irq_find_mapping(domain, irqnr);
ipipe_handle_multi_irq(irqnr, regs);
}
} while (irqnr);
}
asmlinkage void __exception_irq_entry omap2_intc_handle_irq(struct pt_regs *regs)
{
void __iomem *base_addr = OMAP2_IRQ_BASE;
omap_intc_handle_irq(base_addr, regs);
}
int __init intc_of_init(struct device_node *node,
struct device_node *parent)
{
struct resource res;
u32 nr_irq = 96;
if (WARN_ON(!node))
return -ENODEV;
if (of_address_to_resource(node, 0, &res)) {
WARN(1, "unable to get intc registers\n");
return -EINVAL;
}
if (of_property_read_u32(node, "ti,intc-size", &nr_irq))
pr_warn("unable to get intc-size, default to %d\n", nr_irq);
omap_init_irq(res.start, nr_irq, of_node_get(node));
return 0;
}
static struct of_device_id irq_match[] __initdata = {
{ .compatible = "ti,omap2-intc", .data = intc_of_init, },
{ }
};
void __init omap_intc_of_init(void)
{
of_irq_init(irq_match);
}
#if defined(CONFIG_IPIPE) && defined(CONFIG_ARCH_OMAP2PLUS)
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
void omap3_intc_mute(void)
{
struct omap_irq_bank *bank = &irq_banks[0];
intc_bank_write_reg(0x1, bank, INTC_THRESHOLD);
intc_bank_write_reg(0x1, bank, INTC_CONTROL);
}
void omap3_intc_unmute(void)
{
struct omap_irq_bank *bank = &irq_banks[0];
intc_bank_write_reg(0xff, bank, INTC_THRESHOLD);
}
void omap3_intc_set_irq_prio(int irq, int hi)
{
struct omap_irq_bank *bank = &irq_banks[0];
if (irq >= INTCPS_NR_MIR_REGS * 32)
return;
intc_bank_write_reg(hi ? 0 : 0xfc, bank, INTC_PRIO + 4 * irq);
}
#endif /* CONFIG_ARCH_OMAP3 */
#endif /* CONFIG_IPIPE && ARCH_OMAP2PLUS */
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
void omap_intc_save_context(void)
{
int ind = 0, i = 0;
for (ind = 0; ind < ARRAY_SIZE(irq_banks); ind++) {
struct omap_irq_bank *bank = irq_banks + ind;
intc_context[ind].sysconfig =
intc_bank_read_reg(bank, INTC_SYSCONFIG);
intc_context[ind].protection =
intc_bank_read_reg(bank, INTC_PROTECTION);
intc_context[ind].idle =
intc_bank_read_reg(bank, INTC_IDLE);
intc_context[ind].threshold =
intc_bank_read_reg(bank, INTC_THRESHOLD);
for (i = 0; i < INTCPS_NR_IRQS; i++)
intc_context[ind].ilr[i] =
intc_bank_read_reg(bank, (0x100 + 0x4*i));
for (i = 0; i < INTCPS_NR_MIR_REGS; i++)
intc_context[ind].mir[i] =
intc_bank_read_reg(&irq_banks[0], INTC_MIR0 +
(0x20 * i));
}
}
void omap_intc_restore_context(void)
{
int ind = 0, i = 0;
for (ind = 0; ind < ARRAY_SIZE(irq_banks); ind++) {
struct omap_irq_bank *bank = irq_banks + ind;
intc_bank_write_reg(intc_context[ind].sysconfig,
bank, INTC_SYSCONFIG);
intc_bank_write_reg(intc_context[ind].sysconfig,
bank, INTC_SYSCONFIG);
intc_bank_write_reg(intc_context[ind].protection,
bank, INTC_PROTECTION);
intc_bank_write_reg(intc_context[ind].idle,
bank, INTC_IDLE);
intc_bank_write_reg(intc_context[ind].threshold,
bank, INTC_THRESHOLD);
for (i = 0; i < INTCPS_NR_IRQS; i++)
intc_bank_write_reg(intc_context[ind].ilr[i],
bank, (0x100 + 0x4*i));
for (i = 0; i < INTCPS_NR_MIR_REGS; i++)
intc_bank_write_reg(intc_context[ind].mir[i],
&irq_banks[0], INTC_MIR0 + (0x20 * i));
}
/* MIRs are saved and restore with other PRCM registers */
}
void omap3_intc_suspend(void)
{
/* A pending interrupt would prevent OMAP from entering suspend */
omap_ack_irq(NULL);
}
void omap3_intc_prepare_idle(void)
{
/*
* Disable autoidle as it can stall interrupt controller,
* cf. errata ID i540 for 3430 (all revisions up to 3.1.x)
*/
intc_bank_write_reg(0, &irq_banks[0], INTC_SYSCONFIG);
}
void omap3_intc_resume_idle(void)
{
/* Re-enable autoidle */
intc_bank_write_reg(1, &irq_banks[0], INTC_SYSCONFIG);
}
asmlinkage void __exception_irq_entry omap3_intc_handle_irq(struct pt_regs *regs)
{
void __iomem *base_addr = OMAP3_IRQ_BASE;
omap_intc_handle_irq(base_addr, regs);
}
#endif /* CONFIG_ARCH_OMAP3 */
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 9:29 ` Gilles Chanteperdrix
2013-10-17 10:24 ` Ralf Roesch
@ 2013-10-17 12:39 ` Charles Steinkuehler
2013-10-17 15:12 ` Ralf Roesch
2013-10-17 18:43 ` Gilles Chanteperdrix
1 sibling, 2 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-10-17 12:39 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On 10/17/2013 4:29 AM, Gilles Chanteperdrix wrote:
> On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
>> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>>> I'll test with ipipe disabled, go through the Arm Porting guide, and
>>>> see
>>>> where that gets me...
>>>
>>> After building a patched kernel without ipipe or xenomai enabled:
>>>
>>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>>> # CONFIG_XENOMAI is not set
>>> CONFIG_XENO_GENERIC_STACKPOOL=y
>>> CONFIG_XENO_FASTSYNCH_DEP=y
>>> CONFIG_XENO_FASTSYNCH=y
>>> # CONFIG_IPIPE is not set
>>>
>>> ...the mmc issue seems fixed. So according to the porting guide, this
>>> indicates a likely problem with interrupts or the interrupt controller
>>> (as Gilles indicated).
>>
>> Based on the ARM porting guide, the first thing I did was to disable IRQ
>> muting by simply commenting out the two calls to:
>>
>> ipipe_pic_muter_register
>>
>> ...in <linux>/drivers/gpio/gpio-omap.c
>>
>> This results in a kernel that DOES NOT HANG with ipipe enabled!
>
> It does not really make sense: when I-pipe is enabled but Xenomai
> disabled, the PIC muting is only used to tweak the interrupt controller
> priority. Since there are only secondary mode irqs, they all should use
> the same priority.
I am confused as well, particularly by the fact that adding back the
xenomai patches (but leaving the gpio IRQ masking disabled) gets me back
to the hung mmc task.
> Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if yes,
> could you put the modified version somewhere I could have a look at it?
The minor patch to the irq file doesn't seem likely to cause problems,
but there is a *LOT* of mmc driver code that is changed between mainline
and the BeagleBone kernel, much of it related to DMA.
I've put up my full kernel build tree in case you want to look at any
other files. The top directory is the scripts and patches used to build
the kernel. The actual kernel code already patched with the BeagleBone
patch set as well as ipipe and xenomai is in the KERNEL directory:
http://morpheus.steinkuehler.net/xenomai
Are the xenomai patches similar to the preempt-rt patch set in that they
can expose underlying flaws in driver code that is not SMP clean?
If so, I suspect something with the mmc and dma updates specific to the
BeagleBone patch set. Maybe I should be pestering the OMAP kernel list?
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131017/324643fa/attachment.pgp>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 12:39 ` Charles Steinkuehler
@ 2013-10-17 15:12 ` Ralf Roesch
2013-10-17 18:43 ` Gilles Chanteperdrix
1 sibling, 0 replies; 25+ messages in thread
From: Ralf Roesch @ 2013-10-17 15:12 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
On Thu Oct 17 2013 14:39:37 GMT+0200, Charles Steinkuehler
<charles@steinkuehler.net> wrote:
> On 10/17/2013 4:29 AM, Gilles Chanteperdrix wrote:
>> On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
>>> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>>>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>>>> I'll test with ipipe disabled, go through the Arm Porting guide, and
>>>>> see
>>>>> where that gets me...
>>>> After building a patched kernel without ipipe or xenomai enabled:
>>>>
>>>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>>>> # CONFIG_XENOMAI is not set
>>>> CONFIG_XENO_GENERIC_STACKPOOL=y
>>>> CONFIG_XENO_FASTSYNCH_DEP=y
>>>> CONFIG_XENO_FASTSYNCH=y
>>>> # CONFIG_IPIPE is not set
>>>>
>>>> ...the mmc issue seems fixed. So according to the porting guide, this
>>>> indicates a likely problem with interrupts or the interrupt controller
>>>> (as Gilles indicated).
>>> Based on the ARM porting guide, the first thing I did was to disable IRQ
>>> muting by simply commenting out the two calls to:
>>>
>>> ipipe_pic_muter_register
>>>
>>> ...in<linux>/drivers/gpio/gpio-omap.c
>>>
>>> This results in a kernel that DOES NOT HANG with ipipe enabled!
>> It does not really make sense: when I-pipe is enabled but Xenomai
>> disabled, the PIC muting is only used to tweak the interrupt controller
>> priority. Since there are only secondary mode irqs, they all should use
>> the same priority.
> I am confused as well, particularly by the fact that adding back the
> xenomai patches (but leaving the gpio IRQ masking disabled) gets me back
> to the hung mmc task.
>
>> Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if yes,
>> could you put the modified version somewhere I could have a look at it?
> The minor patch to the irq file doesn't seem likely to cause problems,
> but there is a *LOT* of mmc driver code that is changed between mainline
> and the BeagleBone kernel, much of it related to DMA.
If I got it it right the device tree handling is also complete new (
arch / arm / boot / dts /) compared to mainline?
If so, the enhanced DMA (edma) should also be taken into account ?
--
Ralf
> I've put up my full kernel build tree in case you want to look at any
> other files. The top directory is the scripts and patches used to build
> the kernel. The actual kernel code already patched with the BeagleBone
> patch set as well as ipipe and xenomai is in the KERNEL directory:
>
> http://morpheus.steinkuehler.net/xenomai
>
> Are the xenomai patches similar to the preempt-rt patch set in that they
> can expose underlying flaws in driver code that is not SMP clean?
>
> If so, I suspect something with the mmc and dma updates specific to the
> BeagleBone patch set. Maybe I should be pestering the OMAP kernel list?
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 12:39 ` Charles Steinkuehler
2013-10-17 15:12 ` Ralf Roesch
@ 2013-10-17 18:43 ` Gilles Chanteperdrix
2013-11-04 12:38 ` Charles Steinkuehler
1 sibling, 1 reply; 25+ messages in thread
From: Gilles Chanteperdrix @ 2013-10-17 18:43 UTC (permalink / raw)
To: Charles Steinkuehler; +Cc: xenomai
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/17/2013 02:39 PM, Charles Steinkuehler wrote:
> On 10/17/2013 4:29 AM, Gilles Chanteperdrix wrote:
>> On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
>>> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>>>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>>>> I'll test with ipipe disabled, go through the Arm Porting
>>>>> guide, and see where that gets me...
>>>>
>>>> After building a patched kernel without ipipe or xenomai
>>>> enabled:
>>>>
>>>> $ egrep '(IPIPE|XENO)' KERNEL/.config # CONFIG_XENOMAI is not
>>>> set CONFIG_XENO_GENERIC_STACKPOOL=y
>>>> CONFIG_XENO_FASTSYNCH_DEP=y CONFIG_XENO_FASTSYNCH=y #
>>>> CONFIG_IPIPE is not set
>>>>
>>>> ...the mmc issue seems fixed. So according to the porting
>>>> guide, this indicates a likely problem with interrupts or the
>>>> interrupt controller (as Gilles indicated).
>>>
>>> Based on the ARM porting guide, the first thing I did was to
>>> disable IRQ muting by simply commenting out the two calls to:
>>>
>>> ipipe_pic_muter_register
>>>
>>> ...in <linux>/drivers/gpio/gpio-omap.c
>>>
>>> This results in a kernel that DOES NOT HANG with ipipe
>>> enabled!
>>
>> It does not really make sense: when I-pipe is enabled but
>> Xenomai disabled, the PIC muting is only used to tweak the
>> interrupt controller priority. Since there are only secondary
>> mode irqs, they all should use the same priority.
>
> I am confused as well, particularly by the fact that adding back
> the xenomai patches (but leaving the gpio IRQ masking disabled)
> gets me back to the hung mmc task.
No this makes sense: it simply means that the issue has nothing to do
with pic muting. What is surprising is that disabling pic muting
without CONFIG_XENOMAI changes anything: the PIC muting is only used
with CONFIG_XENOMAI except for the setting of the interrupt controller
priority.
>
>> Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches,
>> if yes, could you put the modified version somewhere I could have
>> a look at it?
>
> The minor patch to the irq file doesn't seem likely to cause
> problems, but there is a *LOT* of mmc driver code that is changed
> between mainline and the BeagleBone kernel, much of it related to
> DMA.
>
> I've put up my full kernel build tree in case you want to look at
> any other files. The top directory is the scripts and patches used
> to build the kernel. The actual kernel code already patched with
> the BeagleBone patch set as well as ipipe and xenomai is in the
> KERNEL directory:
>
> http://morpheus.steinkuehler.net/xenomai
>
> Are the xenomai patches similar to the preempt-rt patch set in that
> they can expose underlying flaws in driver code that is not SMP
> clean?
>
> If so, I suspect something with the mmc and dma updates specific to
> the BeagleBone patch set. Maybe I should be pestering the OMAP
> kernel list?
>
As I said in my first answer, the thing that could happen could be
that the driver is not prepared for the interrupt controller to
receive another interrupt while the interrupt line is masked after
receiving the first interrupt, this could be considered a driver bug
which is exposed by the fact that interrupts are masked for a longer
time with the I-pipe patch.
- --
Gilles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iD8DBQFSYC/lGpcgE6m/fboRAiNTAJ9Lgl+5yvZx3tq+A2sNAuV2O+ELEwCfduKz
76kAr5wrhwpuON1H069pPr0=
=EyFB
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel
2013-10-17 18:43 ` Gilles Chanteperdrix
@ 2013-11-04 12:38 ` Charles Steinkuehler
0 siblings, 0 replies; 25+ messages in thread
From: Charles Steinkuehler @ 2013-11-04 12:38 UTC (permalink / raw)
To: xenomai
On 10/17/2013 1:43 PM, Gilles Chanteperdrix wrote:
> On 10/17/2013 02:39 PM, Charles Steinkuehler wrote:
>
>> If so, I suspect something with the mmc and dma updates specific to
>> the BeagleBone patch set. Maybe I should be pestering the OMAP
>> kernel list?
>
> As I said in my first answer, the thing that could happen could be
> that the driver is not prepared for the interrupt controller to
> receive another interrupt while the interrupt line is masked after
> receiving the first interrupt, this could be considered a driver bug
> which is exposed by the fact that interrupts are masked for a longer
> time with the I-pipe patch.
For anyone still following or stumbling across this thread, Ralf Roesch
identified a commit from the 3.12 branch that appears to fix the issue,
both for the Xenomai patched BeagleBone kernel and for the 'standard'
BeagleBone kernel without xenomai patches applied. The odd behavior I
was getting with a 'standard' kernel vs the xenomai patched kernel is
apparently due to my not generating enough stress to trigger the bug
when the xenomai patches were not enabled (it is much easier to generate
the hung task with the xenomai patches applied, but the issue isn't
directly related to xenomai in any way, it's a goof in the status
register handling of the MMC controller).
The patch with the fix from the 3.12 kernel source can be found here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7472bab236bdee1173412585591329e718f4d324
--
Charles Steinkuehler
charles@steinkuehler.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131104/4a5df78e/attachment.sig>
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2013-11-04 12:38 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-15 22:23 [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel Charles Steinkuehler
2013-10-16 10:44 ` Gilles Chanteperdrix
2013-10-16 11:10 ` Charles Steinkuehler
2013-10-16 11:13 ` Gilles Chanteperdrix
2013-10-16 11:09 ` Gilles Chanteperdrix
2013-10-16 11:38 ` Charles Steinkuehler
2013-10-16 11:50 ` Gilles Chanteperdrix
2013-10-16 12:08 ` Charles Steinkuehler
2013-10-16 12:28 ` Charles Steinkuehler
2013-10-16 12:44 ` Gilles Chanteperdrix
2013-10-16 12:52 ` Charles Steinkuehler
2013-10-16 15:25 ` Charles Steinkuehler
2013-10-16 15:58 ` Gilles Chanteperdrix
2013-10-16 16:12 ` Charles Steinkuehler
2013-10-16 19:41 ` Charles Steinkuehler
2013-10-17 0:58 ` Charles Steinkuehler
2013-10-17 2:21 ` Charles Steinkuehler
2013-10-17 9:29 ` Gilles Chanteperdrix
2013-10-17 10:24 ` Ralf Roesch
2013-10-17 12:39 ` Charles Steinkuehler
2013-10-17 15:12 ` Ralf Roesch
2013-10-17 18:43 ` Gilles Chanteperdrix
2013-11-04 12:38 ` Charles Steinkuehler
2013-10-16 18:12 ` Ralf Roesch
2013-10-16 12:51 ` Ralf Roesch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.