All of lore.kernel.org
 help / color / mirror / Atom feed
* ARM: switchtest fails
@ 2020-07-02 10:15 Jan Leupold
  2020-07-02 12:07 ` Greg Gallagher
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Leupold @ 2020-07-02 10:15 UTC (permalink / raw)
  To: Xenomai (xenomai@xenomai.org)

Hi,

I have a problem with switchtest, executed on sama5d2,
ipipe-4.19.128-cip28, xenomai-3.1.

When started without arguments:
== Testing FPU check routines...
d0: 1 != 2
... snip ...
d15: 1 != 2
== FPU check routines: OK.
== Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12
rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18
rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
RTT|  00:00:00
RTH|ctx switches|-------total
RTD|          25|          25

no more output, exit status = 1

When started as "switchtest -n":

== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|        4295|        4295
RTD|        4316|        8611
RTD|        4279|       12890
RTD|        4316|       17206
RTD|        4313|       21519
^C
RTD|        1215|       22734

deliberately terminated by CTRL-C, exit status = 0

Any threadspec of rtus_ufps, rtup_ufpp or rtuo_ufpp will cause the effect.
When looking at the source code I would suspect "fp_regs_set()" to cause it.
The kernel log reports messages like this one:
[Xenomai] rtup_ufpp-1[1599] called regular ioctl() on /dev/rtdm/switchtest

While I have no reason to think that floating point operations are not
OK on this target I would like to at least know why switchtest fails
when using floating point:
* VFP initialization with respect to register access?
* Number of floating point registers? (although NEON should have more than
  the tested 16)
* Any ideas?

Regards,
Jan

Some more details:

CONFIG_VFP, CONFIG_VFPv3 and CONFIG_NEON are set.

trace-cmd record -e cobalt* -e sched* -e signal*
switchtest
trace-cmd report
---> output (at least the portion that seems to me relevant):

... switchtest threads are doing their work, and then comes rtup-ufpp-9 ...
     rtup-8-1538  [000]   135.112086: cobalt_switch_context:
prev_name=rtup-8 prev_pid=1538 prev_prio=1 prev_state=0x48042 ==>
next_name=rtup_ufpp-9 next_pid=1539 next_prio=1
     rtup_ufpp-9-1539  [000]   135.112129: cobalt_head_sysexit:  result=0
     rtup_ufpp-9-1539  [000]   135.112154: cobalt_head_sysentry: syscall=ioctl
     rtup_ufpp-9-1539  [000]   135.112170: cobalt_fd_ioctl:
device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
     rtup_ufpp-9-1539  [000]   135.112192: cobalt_fd_ioctl_status:
device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
     rtup_ufpp-9-1539  [000]   135.112207: cobalt_shadow_gorelax:
reason=syscall
     rtup_ufpp-9-1539  [000]   135.112221: cobalt_lostage_request:
request=c090b004 pid=1539 comm=rtup_ufpp-9
     rtup_ufpp-9-1539  [000]   135.112240: cobalt_thread_suspend: pid=1539
mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
     rtup_ufpp-9-1539  [000]   135.112254: cobalt_schedule:
status=0x10000000
     rtup_ufpp-9-1539  [000]   135.112262: cobalt_switch_context:
prev_name=rtup_ufpp-9 prev_pid=1539 prev_prio=1 prev_state=0x480c0 ==>
next_name=ROOT next_pid=0 next_prio=-1
      switchtest-1530  [000]   135.112308: cobalt_lostage_wakeup: pid=1539
comm=rtup_ufpp-9
      switchtest-1530  [000]   135.112329: sched_waking:
comm=rtup_ufpp-9 pid=1539 prio=98 target_cpu=000
      switchtest-1530  [000]   135.112380: sched_wakeup:
rtup_ufpp-9:1539 [98] success=1 CPU:000
      switchtest-1530  [000]   135.112450: sched_stat_runtime:
comm=switchtest pid=1530 runtime=3009028 [ns] vruntime=22563904956 [ns]
      switchtest-1530  [000]   135.112489: sched_switch:
switchtest:1530 [120] R ==> rtup_ufpp-9:1539 [98]
     rtup_ufpp-9-1539  [000]   135.112561: cobalt_shadow_relaxed:
state=0x480c0 info=0x0
     rtup_ufpp-9-1539  [000]   135.112581: cobalt_fd_ioctl:
device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
     rtup_ufpp-9-1539  [000]   135.112602: cobalt_fd_ioctl_status:
device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
     rtup_ufpp-9-1539  [000]   135.112614: cobalt_head_sysexit:  result=-38
     rtup_ufpp-9-1539  [000]   135.112997: sched_waking:
comm=switchtest pid=1527 prio=120 target_cpu=000
     rtup_ufpp-9-1539  [000]   135.113036: sched_wakeup:
switchtest:1527 [120] success=1 CPU:000
     rtup_ufpp-9-1539  [000]   135.113055: signal_generate:      sig=15
errno=0 code=-6 comm=switchtest pid=1527 grp=0 res=0
     rtup_ufpp-9-1539  [000]   135.113204: sched_switch:
rtup_ufpp-9:1539 [98] S ==> switchtest:1527 [120]
      switchtest-1527  [000]   135.113621: sched_waking:
comm=switchtest pid=1530 prio=120 target_cpu=000
      switchtest-1527  [000]   135.113656: sched_stat_runtime:
comm=switchtest pid=1527 runtime=492337 [ns] vruntime=22561734482 [ns]
      switchtest-1527  [000]   135.113684: sched_wakeup:
switchtest:1530 [120] success=1 CPU:000
      switchtest-1527  [000]   135.113697: signal_generate:      sig=32
errno=0 code=-6 comm=switchtest pid=1530 grp=0 res=0
      switchtest-1527  [000]   135.113805: cobalt_thread_unblock: pid=1537
state=0x48042 info=0x0
      switchtest-1527  [000]   135.113820: cobalt_thread_resume:
name=rtup-7 pid=1537 mask=0x2
      switchtest-1527  [000]   135.113837: cobalt_synch_forget:
synch=0xd92e00e0
      switchtest-1527  [000]   135.113872: cobalt_schedule_remote:
status=0x10000000
      switchtest-1527  [000]   135.113880: cobalt_schedule:
status=0x10000000
      switchtest-1527  [000]   135.113893: cobalt_switch_context:
prev_name=ROOT prev_pid=0 prev_prio=-1 prev_state=0x18008 ==>
next_name=rtup-7 next_pid=1537 next_prio=1
          rtup-7-1537  [000]   135.113948: cobalt_fd_ioctl_status:
device=0xc0b7a988 fd=3 pid=1537 comm=rtup-7
          rtup-7-1537  [000]   135.113972: cobalt_shadow_gorelax: reason=signal
          rtup-7-1537  [000]   135.113985: cobalt_lostage_request:
request=c090b004 pid=1537 comm=rtup-7
          rtup-7-1537  [000]   135.113999: cobalt_thread_suspend: pid=1537
mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
          rtup-7-1537  [000]   135.114013: cobalt_schedule:
status=0x10000000
          rtup-7-1537  [000]   135.114021: cobalt_switch_context:
prev_name=rtup-7 prev_pid=1537 prev_prio=1 prev_state=0x480c0 ==>
next_name=ROOT next_pid=0 next_prio=-1


Mit freundlichen Grüßen

*Jan Leupold*
Entwicklung
Development
-- 
---------------------------------------------------------------------------
R-S-I Logo <https://www.rsi-elektrotechnik.de/>

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestraße 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de <https://www.rsi-elektrotechnik.de/>

Tel: +49 8444 9204-32
Fax: +49 8444 9204-50
leupold@rsi-elektrotechnik.de <mailto:leupold@rsi-elektrotechnik.de>
---------------------------------------------------------------------------

Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548




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

* Re: ARM: switchtest fails
  2020-07-02 10:15 ARM: switchtest fails Jan Leupold
@ 2020-07-02 12:07 ` Greg Gallagher
  2020-07-09 15:22   ` Jan Leupold
  0 siblings, 1 reply; 5+ messages in thread
From: Greg Gallagher @ 2020-07-02 12:07 UTC (permalink / raw)
  To: Jan Leupold; +Cc: Xenomai (xenomai@xenomai.org)

On Thu., Jul. 2, 2020, 6:16 a.m. Jan Leupold via Xenomai <
xenomai@xenomai.org> wrote:

> Hi,
>
> I have a problem with switchtest, executed on sama5d2,
> ipipe-4.19.128-cip28, xenomai-3.1.
>
> When started without arguments:
> == Testing FPU check routines...
> d0: 1 != 2
> ... snip ...
> d15: 1 != 2
> == FPU check routines: OK.
> == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
> rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12
> rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18
> rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
> RTT|  00:00:00
> RTH|ctx switches|-------total
> RTD|          25|          25
>
> no more output, exit status = 1
>
> When started as "switchtest -n":
>
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|        4295|        4295
> RTD|        4316|        8611
> RTD|        4279|       12890
> RTD|        4316|       17206
> RTD|        4313|       21519
> ^C
> RTD|        1215|       22734
>
> deliberately terminated by CTRL-C, exit status = 0
>
> Any threadspec of rtus_ufps, rtup_ufpp or rtuo_ufpp will cause the effect.
> When looking at the source code I would suspect "fp_regs_set()" to cause
> it.
> The kernel log reports messages like this one:
> [Xenomai] rtup_ufpp-1[1599] called regular ioctl() on /dev/rtdm/switchtest
>
> While I have no reason to think that floating point operations are not
> OK on this target I would like to at least know why switchtest fails
> when using floating point:
> * VFP initialization with respect to register access?
> * Number of floating point registers? (although NEON should have more than
>   the tested 16)
> * Any ideas?
>
> Regards,
> Jan
>
> Some more details:
>
> CONFIG_VFP, CONFIG_VFPv3 and CONFIG_NEON are set.
>
> trace-cmd record -e cobalt* -e sched* -e signal*
> switchtest
> trace-cmd report
> ---> output (at least the portion that seems to me relevant):
>
> ... switchtest threads are doing their work, and then comes rtup-ufpp-9 ...
>      rtup-8-1538  [000]   135.112086: cobalt_switch_context:
> prev_name=rtup-8 prev_pid=1538 prev_prio=1 prev_state=0x48042 ==>
> next_name=rtup_ufpp-9 next_pid=1539 next_prio=1
>      rtup_ufpp-9-1539  [000]   135.112129: cobalt_head_sysexit:  result=0
>      rtup_ufpp-9-1539  [000]   135.112154: cobalt_head_sysentry:
> syscall=ioctl
>      rtup_ufpp-9-1539  [000]   135.112170: cobalt_fd_ioctl:
> device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>      rtup_ufpp-9-1539  [000]   135.112192: cobalt_fd_ioctl_status:
> device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>      rtup_ufpp-9-1539  [000]   135.112207: cobalt_shadow_gorelax:
> reason=syscall
>      rtup_ufpp-9-1539  [000]   135.112221: cobalt_lostage_request:
> request=c090b004 pid=1539 comm=rtup_ufpp-9
>      rtup_ufpp-9-1539  [000]   135.112240: cobalt_thread_suspend: pid=1539
> mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>      rtup_ufpp-9-1539  [000]   135.112254: cobalt_schedule:
> status=0x10000000
>      rtup_ufpp-9-1539  [000]   135.112262: cobalt_switch_context:
> prev_name=rtup_ufpp-9 prev_pid=1539 prev_prio=1 prev_state=0x480c0 ==>
> next_name=ROOT next_pid=0 next_prio=-1
>       switchtest-1530  [000]   135.112308: cobalt_lostage_wakeup: pid=1539
> comm=rtup_ufpp-9
>       switchtest-1530  [000]   135.112329: sched_waking:
> comm=rtup_ufpp-9 pid=1539 prio=98 target_cpu=000
>       switchtest-1530  [000]   135.112380: sched_wakeup:
> rtup_ufpp-9:1539 [98] success=1 CPU:000
>       switchtest-1530  [000]   135.112450: sched_stat_runtime:
> comm=switchtest pid=1530 runtime=3009028 [ns] vruntime=22563904956 [ns]
>       switchtest-1530  [000]   135.112489: sched_switch:
> switchtest:1530 [120] R ==> rtup_ufpp-9:1539 [98]
>      rtup_ufpp-9-1539  [000]   135.112561: cobalt_shadow_relaxed:
> state=0x480c0 info=0x0
>      rtup_ufpp-9-1539  [000]   135.112581: cobalt_fd_ioctl:
> device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>      rtup_ufpp-9-1539  [000]   135.112602: cobalt_fd_ioctl_status:
> device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>      rtup_ufpp-9-1539  [000]   135.112614: cobalt_head_sysexit:  result=-38
>      rtup_ufpp-9-1539  [000]   135.112997: sched_waking:
> comm=switchtest pid=1527 prio=120 target_cpu=000
>      rtup_ufpp-9-1539  [000]   135.113036: sched_wakeup:
> switchtest:1527 [120] success=1 CPU:000
>      rtup_ufpp-9-1539  [000]   135.113055: signal_generate:      sig=15
> errno=0 code=-6 comm=switchtest pid=1527 grp=0 res=0
>      rtup_ufpp-9-1539  [000]   135.113204: sched_switch:
> rtup_ufpp-9:1539 [98] S ==> switchtest:1527 [120]
>       switchtest-1527  [000]   135.113621: sched_waking:
> comm=switchtest pid=1530 prio=120 target_cpu=000
>       switchtest-1527  [000]   135.113656: sched_stat_runtime:
> comm=switchtest pid=1527 runtime=492337 [ns] vruntime=22561734482 [ns]
>       switchtest-1527  [000]   135.113684: sched_wakeup:
> switchtest:1530 [120] success=1 CPU:000
>       switchtest-1527  [000]   135.113697: signal_generate:      sig=32
> errno=0 code=-6 comm=switchtest pid=1530 grp=0 res=0
>       switchtest-1527  [000]   135.113805: cobalt_thread_unblock: pid=1537
> state=0x48042 info=0x0
>       switchtest-1527  [000]   135.113820: cobalt_thread_resume:
> name=rtup-7 pid=1537 mask=0x2
>       switchtest-1527  [000]   135.113837: cobalt_synch_forget:
> synch=0xd92e00e0
>       switchtest-1527  [000]   135.113872: cobalt_schedule_remote:
> status=0x10000000
>       switchtest-1527  [000]   135.113880: cobalt_schedule:
> status=0x10000000
>       switchtest-1527  [000]   135.113893: cobalt_switch_context:
> prev_name=ROOT prev_pid=0 prev_prio=-1 prev_state=0x18008 ==>
> next_name=rtup-7 next_pid=1537 next_prio=1
>           rtup-7-1537  [000]   135.113948: cobalt_fd_ioctl_status:
> device=0xc0b7a988 fd=3 pid=1537 comm=rtup-7
>           rtup-7-1537  [000]   135.113972: cobalt_shadow_gorelax:
> reason=signal
>           rtup-7-1537  [000]   135.113985: cobalt_lostage_request:
> request=c090b004 pid=1537 comm=rtup-7
>           rtup-7-1537  [000]   135.113999: cobalt_thread_suspend: pid=1537
> mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>           rtup-7-1537  [000]   135.114013: cobalt_schedule:
> status=0x10000000
>           rtup-7-1537  [000]   135.114021: cobalt_switch_context:
> prev_name=rtup-7 prev_pid=1537 prev_prio=1 prev_state=0x480c0 ==>
> next_name=ROOT next_pid=0 next_prio=-1
>
>
> Mit freundlichen Grüßen
>
> *Jan Leupold*
> Entwicklung
> Development
> --
>
I can take a look and see if I can reproduce on another arm platform. I'm
not too familiar with this test but I'll run it and see if there's anything
unusual on the ipipe side of things.

-Greg


---------------------------------------------------------------------------
> R-S-I Logo <https://www.rsi-elektrotechnik.de/>
>
> R-S-I Elektrotechnik GmbH & Co. KG
> Woelkestraße 11
> D-85301 Schweitenkirchen
> www.rsi-elektrotechnik.de <https://www.rsi-elektrotechnik.de/>
>
> Tel: +49 8444 9204-32
> Fax: +49 8444 9204-50
> leupold@rsi-elektrotechnik.de <mailto:leupold@rsi-elektrotechnik.de>
> ---------------------------------------------------------------------------
>
> Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
> Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> USt-IdNr.: DE 128592548
>
>
>
>

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

* Re: ARM: switchtest fails
  2020-07-02 12:07 ` Greg Gallagher
@ 2020-07-09 15:22   ` Jan Leupold
  2020-07-13 17:08     ` Jan Kiszka
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Leupold @ 2020-07-09 15:22 UTC (permalink / raw)
  To: Xenomai (xenomai@xenomai.org)

Hi Greg,

Am 02.07.20 um 14:07 schrieb Greg Gallagher:
> 
> 
> On Thu., Jul. 2, 2020, 6:16 a.m. Jan Leupold via Xenomai
> <xenomai@xenomai.org <mailto:xenomai@xenomai.org>> wrote:
> 
>     Hi,
> 
>     I have a problem with switchtest, executed on sama5d2,
>     ipipe-4.19.128-cip28, xenomai-3.1.
> 
>     When started without arguments:
>     == Testing FPU check routines...
>     d0: 1 != 2
>     ... snip ...
>     d15: 1 != 2
>     == FPU check routines: OK.
>     == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
>     rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12
>     rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18
>     rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
>     RTT|  00:00:00
>     RTH|ctx switches|-------total
>     RTD|          25|          25
> 
>     no more output, exit status = 1
> 
>     When started as "switchtest -n":
> 
>     == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
>     RTT|  00:00:01
>     RTH|ctx switches|-------total
>     RTD|        4295|        4295
>     RTD|        4316|        8611
>     RTD|        4279|       12890
>     RTD|        4316|       17206
>     RTD|        4313|       21519
>     ^C
>     RTD|        1215|       22734
> 
>     deliberately terminated by CTRL-C, exit status = 0
> 
>     Any threadspec of rtus_ufps, rtup_ufpp or rtuo_ufpp will cause the effect.
>     When looking at the source code I would suspect "fp_regs_set()" to
>     cause it.
>     The kernel log reports messages like this one:
>     [Xenomai] rtup_ufpp-1[1599] called regular ioctl() on /dev/rtdm/switchtest
> 
>     While I have no reason to think that floating point operations are not
>     OK on this target I would like to at least know why switchtest fails
>     when using floating point:
>     * VFP initialization with respect to register access?
>     * Number of floating point registers? (although NEON should have more than
>       the tested 16)
>     * Any ideas?
> 
>     Regards,
>     Jan
> 
>     Some more details:
> 
>     CONFIG_VFP, CONFIG_VFPv3 and CONFIG_NEON are set.
> 
>     trace-cmd record -e cobalt* -e sched* -e signal*
>     switchtest
>     trace-cmd report
>     ---> output (at least the portion that seems to me relevant):
> 
>     ... switchtest threads are doing their work, and then comes rtup-ufpp-9 ...
>          rtup-8-1538  [000]   135.112086: cobalt_switch_context:
>     prev_name=rtup-8 prev_pid=1538 prev_prio=1 prev_state=0x48042 ==>
>     next_name=rtup_ufpp-9 next_pid=1539 next_prio=1
>          rtup_ufpp-9-1539  [000]   135.112129: cobalt_head_sysexit:  result=0
>          rtup_ufpp-9-1539  [000]   135.112154: cobalt_head_sysentry:
>     syscall=ioctl
>          rtup_ufpp-9-1539  [000]   135.112170: cobalt_fd_ioctl:
>     device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>          rtup_ufpp-9-1539  [000]   135.112192: cobalt_fd_ioctl_status:
>     device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>          rtup_ufpp-9-1539  [000]   135.112207: cobalt_shadow_gorelax:
>     reason=syscall
>          rtup_ufpp-9-1539  [000]   135.112221: cobalt_lostage_request:
>     request=c090b004 pid=1539 comm=rtup_ufpp-9
>          rtup_ufpp-9-1539  [000]   135.112240: cobalt_thread_suspend: pid=1539
>     mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>          rtup_ufpp-9-1539  [000]   135.112254: cobalt_schedule:
>     status=0x10000000
>          rtup_ufpp-9-1539  [000]   135.112262: cobalt_switch_context:
>     prev_name=rtup_ufpp-9 prev_pid=1539 prev_prio=1 prev_state=0x480c0 ==>
>     next_name=ROOT next_pid=0 next_prio=-1
>           switchtest-1530  [000]   135.112308: cobalt_lostage_wakeup: pid=1539
>     comm=rtup_ufpp-9
>           switchtest-1530  [000]   135.112329: sched_waking:
>     comm=rtup_ufpp-9 pid=1539 prio=98 target_cpu=000
>           switchtest-1530  [000]   135.112380: sched_wakeup:
>     rtup_ufpp-9:1539 [98] success=1 CPU:000
>           switchtest-1530  [000]   135.112450: sched_stat_runtime:
>     comm=switchtest pid=1530 runtime=3009028 [ns] vruntime=22563904956 [ns]
>           switchtest-1530  [000]   135.112489: sched_switch:
>     switchtest:1530 [120] R ==> rtup_ufpp-9:1539 [98]
>          rtup_ufpp-9-1539  [000]   135.112561: cobalt_shadow_relaxed:
>     state=0x480c0 info=0x0
>          rtup_ufpp-9-1539  [000]   135.112581: cobalt_fd_ioctl:
>     device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>          rtup_ufpp-9-1539  [000]   135.112602: cobalt_fd_ioctl_status:
>     device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>          rtup_ufpp-9-1539  [000]   135.112614: cobalt_head_sysexit:  result=-38
>          rtup_ufpp-9-1539  [000]   135.112997: sched_waking:
>     comm=switchtest pid=1527 prio=120 target_cpu=000
>          rtup_ufpp-9-1539  [000]   135.113036: sched_wakeup:
>     switchtest:1527 [120] success=1 CPU:000
>          rtup_ufpp-9-1539  [000]   135.113055: signal_generate:      sig=15
>     errno=0 code=-6 comm=switchtest pid=1527 grp=0 res=0
>          rtup_ufpp-9-1539  [000]   135.113204: sched_switch:
>     rtup_ufpp-9:1539 [98] S ==> switchtest:1527 [120]
>           switchtest-1527  [000]   135.113621: sched_waking:
>     comm=switchtest pid=1530 prio=120 target_cpu=000
>           switchtest-1527  [000]   135.113656: sched_stat_runtime:
>     comm=switchtest pid=1527 runtime=492337 [ns] vruntime=22561734482 [ns]
>           switchtest-1527  [000]   135.113684: sched_wakeup:
>     switchtest:1530 [120] success=1 CPU:000
>           switchtest-1527  [000]   135.113697: signal_generate:      sig=32
>     errno=0 code=-6 comm=switchtest pid=1530 grp=0 res=0
>           switchtest-1527  [000]   135.113805: cobalt_thread_unblock: pid=1537
>     state=0x48042 info=0x0
>           switchtest-1527  [000]   135.113820: cobalt_thread_resume:
>     name=rtup-7 pid=1537 mask=0x2
>           switchtest-1527  [000]   135.113837: cobalt_synch_forget:
>     synch=0xd92e00e0
>           switchtest-1527  [000]   135.113872: cobalt_schedule_remote:
>     status=0x10000000
>           switchtest-1527  [000]   135.113880: cobalt_schedule:
>     status=0x10000000
>           switchtest-1527  [000]   135.113893: cobalt_switch_context:
>     prev_name=ROOT prev_pid=0 prev_prio=-1 prev_state=0x18008 ==>
>     next_name=rtup-7 next_pid=1537 next_prio=1
>               rtup-7-1537  [000]   135.113948: cobalt_fd_ioctl_status:
>     device=0xc0b7a988 fd=3 pid=1537 comm=rtup-7
>               rtup-7-1537  [000]   135.113972: cobalt_shadow_gorelax:
>     reason=signal
>               rtup-7-1537  [000]   135.113985: cobalt_lostage_request:
>     request=c090b004 pid=1537 comm=rtup-7
>               rtup-7-1537  [000]   135.113999: cobalt_thread_suspend: pid=1537
>     mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>               rtup-7-1537  [000]   135.114013: cobalt_schedule:
>     status=0x10000000
>               rtup-7-1537  [000]   135.114021: cobalt_switch_context:
>     prev_name=rtup-7 prev_pid=1537 prev_prio=1 prev_state=0x480c0 ==>
>     next_name=ROOT next_pid=0 next_prio=-1
> 
> 
>     Mit freundlichen Grüßen
> 
>     *Jan Leupold*
>     Entwicklung
>     Development
>     -- 
> 
> I can take a look and see if I can reproduce on another arm platform. I'm
> not too familiar with this test but I'll run it and see if there's anything
> unusual on the ipipe side of things.
> 
> -Greg
> 

Thanks for trying it out on other platforms! I think I found a way now
to get switchtest working:
When I use DEFAULTTUNE="cortexa5thf-neon-vfpv4" (in yocto) instead of
"cortexa5thf", it executes without any problems on my target.

Regards,
Jan


> 
>     ---------------------------------------------------------------------------
>     R-S-I Logo <https://www.rsi-elektrotechnik.de/>
> 
>     R-S-I Elektrotechnik GmbH & Co. KG
>     Woelkestraße 11
>     D-85301 Schweitenkirchen
>     www.rsi-elektrotechnik.de <http://www.rsi-elektrotechnik.de>
>     <https://www.rsi-elektrotechnik.de/>
> 
>     Tel: +49 8444 9204-32
>     Fax: +49 8444 9204-50
>     leupold@rsi-elektrotechnik.de <mailto:leupold@rsi-elektrotechnik.de>
>     <mailto:leupold@rsi-elektrotechnik.de
>     <mailto:leupold@rsi-elektrotechnik.de>>
>     ---------------------------------------------------------------------------
> 
>     Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
>     Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
>     USt-IdNr.: DE 128592548
> 
> 
> 




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

* Re: ARM: switchtest fails
  2020-07-09 15:22   ` Jan Leupold
@ 2020-07-13 17:08     ` Jan Kiszka
  2020-07-14  6:34       ` Jan Leupold
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2020-07-13 17:08 UTC (permalink / raw)
  To: Jan Leupold, Xenomai (xenomai@xenomai.org)

On 09.07.20 17:22, Jan Leupold via Xenomai wrote:
> Hi Greg,
> 
> Am 02.07.20 um 14:07 schrieb Greg Gallagher:
>>
>>
>> On Thu., Jul. 2, 2020, 6:16 a.m. Jan Leupold via Xenomai
>> <xenomai@xenomai.org <mailto:xenomai@xenomai.org>> wrote:
>>
>>      Hi,
>>
>>      I have a problem with switchtest, executed on sama5d2,
>>      ipipe-4.19.128-cip28, xenomai-3.1.
>>
>>      When started without arguments:
>>      == Testing FPU check routines...
>>      d0: 1 != 2
>>      ... snip ...
>>      d15: 1 != 2
>>      == FPU check routines: OK.
>>      == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
>>      rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12
>>      rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18
>>      rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
>>      RTT|  00:00:00
>>      RTH|ctx switches|-------total
>>      RTD|          25|          25
>>
>>      no more output, exit status = 1
>>
>>      When started as "switchtest -n":
>>
>>      == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
>>      RTT|  00:00:01
>>      RTH|ctx switches|-------total
>>      RTD|        4295|        4295
>>      RTD|        4316|        8611
>>      RTD|        4279|       12890
>>      RTD|        4316|       17206
>>      RTD|        4313|       21519
>>      ^C
>>      RTD|        1215|       22734
>>
>>      deliberately terminated by CTRL-C, exit status = 0
>>
>>      Any threadspec of rtus_ufps, rtup_ufpp or rtuo_ufpp will cause the effect.
>>      When looking at the source code I would suspect "fp_regs_set()" to
>>      cause it.
>>      The kernel log reports messages like this one:
>>      [Xenomai] rtup_ufpp-1[1599] called regular ioctl() on /dev/rtdm/switchtest
>>
>>      While I have no reason to think that floating point operations are not
>>      OK on this target I would like to at least know why switchtest fails
>>      when using floating point:
>>      * VFP initialization with respect to register access?
>>      * Number of floating point registers? (although NEON should have more than
>>        the tested 16)
>>      * Any ideas?
>>
>>      Regards,
>>      Jan
>>
>>      Some more details:
>>
>>      CONFIG_VFP, CONFIG_VFPv3 and CONFIG_NEON are set.
>>
>>      trace-cmd record -e cobalt* -e sched* -e signal*
>>      switchtest
>>      trace-cmd report
>>      ---> output (at least the portion that seems to me relevant):
>>
>>      ... switchtest threads are doing their work, and then comes rtup-ufpp-9 ...
>>           rtup-8-1538  [000]   135.112086: cobalt_switch_context:
>>      prev_name=rtup-8 prev_pid=1538 prev_prio=1 prev_state=0x48042 ==>
>>      next_name=rtup_ufpp-9 next_pid=1539 next_prio=1
>>           rtup_ufpp-9-1539  [000]   135.112129: cobalt_head_sysexit:  result=0
>>           rtup_ufpp-9-1539  [000]   135.112154: cobalt_head_sysentry:
>>      syscall=ioctl
>>           rtup_ufpp-9-1539  [000]   135.112170: cobalt_fd_ioctl:
>>      device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>>           rtup_ufpp-9-1539  [000]   135.112192: cobalt_fd_ioctl_status:
>>      device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>>           rtup_ufpp-9-1539  [000]   135.112207: cobalt_shadow_gorelax:
>>      reason=syscall
>>           rtup_ufpp-9-1539  [000]   135.112221: cobalt_lostage_request:
>>      request=c090b004 pid=1539 comm=rtup_ufpp-9
>>           rtup_ufpp-9-1539  [000]   135.112240: cobalt_thread_suspend: pid=1539
>>      mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>>           rtup_ufpp-9-1539  [000]   135.112254: cobalt_schedule:
>>      status=0x10000000
>>           rtup_ufpp-9-1539  [000]   135.112262: cobalt_switch_context:
>>      prev_name=rtup_ufpp-9 prev_pid=1539 prev_prio=1 prev_state=0x480c0 ==>
>>      next_name=ROOT next_pid=0 next_prio=-1
>>            switchtest-1530  [000]   135.112308: cobalt_lostage_wakeup: pid=1539
>>      comm=rtup_ufpp-9
>>            switchtest-1530  [000]   135.112329: sched_waking:
>>      comm=rtup_ufpp-9 pid=1539 prio=98 target_cpu=000
>>            switchtest-1530  [000]   135.112380: sched_wakeup:
>>      rtup_ufpp-9:1539 [98] success=1 CPU:000
>>            switchtest-1530  [000]   135.112450: sched_stat_runtime:
>>      comm=switchtest pid=1530 runtime=3009028 [ns] vruntime=22563904956 [ns]
>>            switchtest-1530  [000]   135.112489: sched_switch:
>>      switchtest:1530 [120] R ==> rtup_ufpp-9:1539 [98]
>>           rtup_ufpp-9-1539  [000]   135.112561: cobalt_shadow_relaxed:
>>      state=0x480c0 info=0x0
>>           rtup_ufpp-9-1539  [000]   135.112581: cobalt_fd_ioctl:
>>      device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>>           rtup_ufpp-9-1539  [000]   135.112602: cobalt_fd_ioctl_status:
>>      device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>>           rtup_ufpp-9-1539  [000]   135.112614: cobalt_head_sysexit:  result=-38
>>           rtup_ufpp-9-1539  [000]   135.112997: sched_waking:
>>      comm=switchtest pid=1527 prio=120 target_cpu=000
>>           rtup_ufpp-9-1539  [000]   135.113036: sched_wakeup:
>>      switchtest:1527 [120] success=1 CPU:000
>>           rtup_ufpp-9-1539  [000]   135.113055: signal_generate:      sig=15
>>      errno=0 code=-6 comm=switchtest pid=1527 grp=0 res=0
>>           rtup_ufpp-9-1539  [000]   135.113204: sched_switch:
>>      rtup_ufpp-9:1539 [98] S ==> switchtest:1527 [120]
>>            switchtest-1527  [000]   135.113621: sched_waking:
>>      comm=switchtest pid=1530 prio=120 target_cpu=000
>>            switchtest-1527  [000]   135.113656: sched_stat_runtime:
>>      comm=switchtest pid=1527 runtime=492337 [ns] vruntime=22561734482 [ns]
>>            switchtest-1527  [000]   135.113684: sched_wakeup:
>>      switchtest:1530 [120] success=1 CPU:000
>>            switchtest-1527  [000]   135.113697: signal_generate:      sig=32
>>      errno=0 code=-6 comm=switchtest pid=1530 grp=0 res=0
>>            switchtest-1527  [000]   135.113805: cobalt_thread_unblock: pid=1537
>>      state=0x48042 info=0x0
>>            switchtest-1527  [000]   135.113820: cobalt_thread_resume:
>>      name=rtup-7 pid=1537 mask=0x2
>>            switchtest-1527  [000]   135.113837: cobalt_synch_forget:
>>      synch=0xd92e00e0
>>            switchtest-1527  [000]   135.113872: cobalt_schedule_remote:
>>      status=0x10000000
>>            switchtest-1527  [000]   135.113880: cobalt_schedule:
>>      status=0x10000000
>>            switchtest-1527  [000]   135.113893: cobalt_switch_context:
>>      prev_name=ROOT prev_pid=0 prev_prio=-1 prev_state=0x18008 ==>
>>      next_name=rtup-7 next_pid=1537 next_prio=1
>>                rtup-7-1537  [000]   135.113948: cobalt_fd_ioctl_status:
>>      device=0xc0b7a988 fd=3 pid=1537 comm=rtup-7
>>                rtup-7-1537  [000]   135.113972: cobalt_shadow_gorelax:
>>      reason=signal
>>                rtup-7-1537  [000]   135.113985: cobalt_lostage_request:
>>      request=c090b004 pid=1537 comm=rtup-7
>>                rtup-7-1537  [000]   135.113999: cobalt_thread_suspend: pid=1537
>>      mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>>                rtup-7-1537  [000]   135.114013: cobalt_schedule:
>>      status=0x10000000
>>                rtup-7-1537  [000]   135.114021: cobalt_switch_context:
>>      prev_name=rtup-7 prev_pid=1537 prev_prio=1 prev_state=0x480c0 ==>
>>      next_name=ROOT next_pid=0 next_prio=-1
>>
>>
>>      Mit freundlichen Grüßen
>>
>>      *Jan Leupold*
>>      Entwicklung
>>      Development
>>      --
>>
>> I can take a look and see if I can reproduce on another arm platform. I'm
>> not too familiar with this test but I'll run it and see if there's anything
>> unusual on the ipipe side of things.
>>
>> -Greg
>>
> 
> Thanks for trying it out on other platforms! I think I found a way now
> to get switchtest working:
> When I use DEFAULTTUNE="cortexa5thf-neon-vfpv4" (in yocto) instead of
> "cortexa5thf", it executes without any problems on my target.

I'm not an expert in the semantics of these tuning - do they make sense 
as well, or are we still facing a not fully understood issue here?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


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

* Re: ARM: switchtest fails
  2020-07-13 17:08     ` Jan Kiszka
@ 2020-07-14  6:34       ` Jan Leupold
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Leupold @ 2020-07-14  6:34 UTC (permalink / raw)
  To: Jan Kiszka, Xenomai (xenomai@xenomai.org)

Am 13.07.20 um 19:08 schrieb Jan Kiszka:
> On 09.07.20 17:22, Jan Leupold via Xenomai wrote:
>> Hi Greg,
>>
>> Am 02.07.20 um 14:07 schrieb Greg Gallagher:
>>>
>>>
>>> On Thu., Jul. 2, 2020, 6:16 a.m. Jan Leupold via Xenomai
>>> <xenomai@xenomai.org <mailto:xenomai@xenomai.org>> wrote:
>>>
>>>      Hi,
>>>
>>>      I have a problem with switchtest, executed on sama5d2,
>>>      ipipe-4.19.128-cip28, xenomai-3.1.
>>>
>>>      When started without arguments:
>>>      == Testing FPU check routines...
>>>      d0: 1 != 2
>>>      ... snip ...
>>>      d15: 1 != 2
>>>      == FPU check routines: OK.
>>>      == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5
>>>      rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12
>>>      rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18
>>>      rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22
>>>      RTT|  00:00:00
>>>      RTH|ctx switches|-------total
>>>      RTD|          25|          25
>>>
>>>      no more output, exit status = 1
>>>
>>>      When started as "switchtest -n":
>>>
>>>      == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6
>>> rtuo-7 rtuo-8
>>>      RTT|  00:00:01
>>>      RTH|ctx switches|-------total
>>>      RTD|        4295|        4295
>>>      RTD|        4316|        8611
>>>      RTD|        4279|       12890
>>>      RTD|        4316|       17206
>>>      RTD|        4313|       21519
>>>      ^C
>>>      RTD|        1215|       22734
>>>
>>>      deliberately terminated by CTRL-C, exit status = 0
>>>
>>>      Any threadspec of rtus_ufps, rtup_ufpp or rtuo_ufpp will cause the
>>> effect.
>>>      When looking at the source code I would suspect "fp_regs_set()" to
>>>      cause it.
>>>      The kernel log reports messages like this one:
>>>      [Xenomai] rtup_ufpp-1[1599] called regular ioctl() on
>>> /dev/rtdm/switchtest
>>>
>>>      While I have no reason to think that floating point operations are not
>>>      OK on this target I would like to at least know why switchtest fails
>>>      when using floating point:
>>>      * VFP initialization with respect to register access?
>>>      * Number of floating point registers? (although NEON should have
>>> more than
>>>        the tested 16)
>>>      * Any ideas?
>>>
>>>      Regards,
>>>      Jan
>>>
>>>      Some more details:
>>>
>>>      CONFIG_VFP, CONFIG_VFPv3 and CONFIG_NEON are set.
>>>
>>>      trace-cmd record -e cobalt* -e sched* -e signal*
>>>      switchtest
>>>      trace-cmd report
>>>      ---> output (at least the portion that seems to me relevant):
>>>
>>>      ... switchtest threads are doing their work, and then comes
>>> rtup-ufpp-9 ...
>>>           rtup-8-1538  [000]   135.112086: cobalt_switch_context:
>>>      prev_name=rtup-8 prev_pid=1538 prev_prio=1 prev_state=0x48042 ==>
>>>      next_name=rtup_ufpp-9 next_pid=1539 next_prio=1
>>>           rtup_ufpp-9-1539  [000]   135.112129: cobalt_head_sysexit: 
>>> result=0
>>>           rtup_ufpp-9-1539  [000]   135.112154: cobalt_head_sysentry:
>>>      syscall=ioctl
>>>           rtup_ufpp-9-1539  [000]   135.112170: cobalt_fd_ioctl:
>>>      device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>>>           rtup_ufpp-9-1539  [000]   135.112192: cobalt_fd_ioctl_status:
>>>      device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>>>           rtup_ufpp-9-1539  [000]   135.112207: cobalt_shadow_gorelax:
>>>      reason=syscall
>>>           rtup_ufpp-9-1539  [000]   135.112221: cobalt_lostage_request:
>>>      request=c090b004 pid=1539 comm=rtup_ufpp-9
>>>           rtup_ufpp-9-1539  [000]   135.112240: cobalt_thread_suspend:
>>> pid=1539
>>>      mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>>>           rtup_ufpp-9-1539  [000]   135.112254: cobalt_schedule:
>>>      status=0x10000000
>>>           rtup_ufpp-9-1539  [000]   135.112262: cobalt_switch_context:
>>>      prev_name=rtup_ufpp-9 prev_pid=1539 prev_prio=1 prev_state=0x480c0 ==>
>>>      next_name=ROOT next_pid=0 next_prio=-1
>>>            switchtest-1530  [000]   135.112308: cobalt_lostage_wakeup:
>>> pid=1539
>>>      comm=rtup_ufpp-9
>>>            switchtest-1530  [000]   135.112329: sched_waking:
>>>      comm=rtup_ufpp-9 pid=1539 prio=98 target_cpu=000
>>>            switchtest-1530  [000]   135.112380: sched_wakeup:
>>>      rtup_ufpp-9:1539 [98] success=1 CPU:000
>>>            switchtest-1530  [000]   135.112450: sched_stat_runtime:
>>>      comm=switchtest pid=1530 runtime=3009028 [ns] vruntime=22563904956
>>> [ns]
>>>            switchtest-1530  [000]   135.112489: sched_switch:
>>>      switchtest:1530 [120] R ==> rtup_ufpp-9:1539 [98]
>>>           rtup_ufpp-9-1539  [000]   135.112561: cobalt_shadow_relaxed:
>>>      state=0x480c0 info=0x0
>>>           rtup_ufpp-9-1539  [000]   135.112581: cobalt_fd_ioctl:
>>>      device=0xc0b7a988 fd=3 arg=0x9 pid=1539 comm=rtup_ufpp-9
>>>           rtup_ufpp-9-1539  [000]   135.112602: cobalt_fd_ioctl_status:
>>>      device=0xc0b7a988 fd=3 pid=1539 comm=rtup_ufpp-9
>>>           rtup_ufpp-9-1539  [000]   135.112614: cobalt_head_sysexit: 
>>> result=-38
>>>           rtup_ufpp-9-1539  [000]   135.112997: sched_waking:
>>>      comm=switchtest pid=1527 prio=120 target_cpu=000
>>>           rtup_ufpp-9-1539  [000]   135.113036: sched_wakeup:
>>>      switchtest:1527 [120] success=1 CPU:000
>>>           rtup_ufpp-9-1539  [000]   135.113055: signal_generate:     
>>> sig=15
>>>      errno=0 code=-6 comm=switchtest pid=1527 grp=0 res=0
>>>           rtup_ufpp-9-1539  [000]   135.113204: sched_switch:
>>>      rtup_ufpp-9:1539 [98] S ==> switchtest:1527 [120]
>>>            switchtest-1527  [000]   135.113621: sched_waking:
>>>      comm=switchtest pid=1530 prio=120 target_cpu=000
>>>            switchtest-1527  [000]   135.113656: sched_stat_runtime:
>>>      comm=switchtest pid=1527 runtime=492337 [ns] vruntime=22561734482 [ns]
>>>            switchtest-1527  [000]   135.113684: sched_wakeup:
>>>      switchtest:1530 [120] success=1 CPU:000
>>>            switchtest-1527  [000]   135.113697: signal_generate:     
>>> sig=32
>>>      errno=0 code=-6 comm=switchtest pid=1530 grp=0 res=0
>>>            switchtest-1527  [000]   135.113805: cobalt_thread_unblock:
>>> pid=1537
>>>      state=0x48042 info=0x0
>>>            switchtest-1527  [000]   135.113820: cobalt_thread_resume:
>>>      name=rtup-7 pid=1537 mask=0x2
>>>            switchtest-1527  [000]   135.113837: cobalt_synch_forget:
>>>      synch=0xd92e00e0
>>>            switchtest-1527  [000]   135.113872: cobalt_schedule_remote:
>>>      status=0x10000000
>>>            switchtest-1527  [000]   135.113880: cobalt_schedule:
>>>      status=0x10000000
>>>            switchtest-1527  [000]   135.113893: cobalt_switch_context:
>>>      prev_name=ROOT prev_pid=0 prev_prio=-1 prev_state=0x18008 ==>
>>>      next_name=rtup-7 next_pid=1537 next_prio=1
>>>                rtup-7-1537  [000]   135.113948: cobalt_fd_ioctl_status:
>>>      device=0xc0b7a988 fd=3 pid=1537 comm=rtup-7
>>>                rtup-7-1537  [000]   135.113972: cobalt_shadow_gorelax:
>>>      reason=signal
>>>                rtup-7-1537  [000]   135.113985: cobalt_lostage_request:
>>>      request=c090b004 pid=1537 comm=rtup-7
>>>                rtup-7-1537  [000]   135.113999: cobalt_thread_suspend:
>>> pid=1537
>>>      mask=0x80 timeout=0 timeout_mode=0 wchan=(nil)
>>>                rtup-7-1537  [000]   135.114013: cobalt_schedule:
>>>      status=0x10000000
>>>                rtup-7-1537  [000]   135.114021: cobalt_switch_context:
>>>      prev_name=rtup-7 prev_pid=1537 prev_prio=1 prev_state=0x480c0 ==>
>>>      next_name=ROOT next_pid=0 next_prio=-1
>>>
>>>
>>>      Mit freundlichen Grüßen
>>>
>>>      *Jan Leupold*
>>>      Entwicklung
>>>      Development
>>>      --
>>>
>>> I can take a look and see if I can reproduce on another arm platform. I'm
>>> not too familiar with this test but I'll run it and see if there's anything
>>> unusual on the ipipe side of things.
>>>
>>> -Greg
>>>
>>
>> Thanks for trying it out on other platforms! I think I found a way now
>> to get switchtest working:
>> When I use DEFAULTTUNE="cortexa5thf-neon-vfpv4" (in yocto) instead of
>> "cortexa5thf", it executes without any problems on my target.
> 
> I'm not an expert in the semantics of these tuning - do they make sense as
> well, or are we still facing a not fully understood issue here?
> 

The effect of changing DEFAULTTUNE is that "-mfpu=vfp" changes to
"-mfpu=neon-vfpv4" on gcc invocation. The disassembly of both
switchtest binaries is hard to compare ... especially if you don't know
what to search. No obvious abnormalities found so far.

Jan

-- 
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548



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

end of thread, other threads:[~2020-07-14  6:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-02 10:15 ARM: switchtest fails Jan Leupold
2020-07-02 12:07 ` Greg Gallagher
2020-07-09 15:22   ` Jan Leupold
2020-07-13 17:08     ` Jan Kiszka
2020-07-14  6:34       ` Jan Leupold

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.