[Xenomai] Support of Beagleboard xm rev C on 3.14-ipipe
Arnaud Degroote
arnaud.degroote at isae.fr
Thu Jun 26 13:19:49 CEST 2014
On 26/Jun - 13:08, Gilles Chanteperdrix wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/26/2014 09:56 AM, Arnaud Degroote wrote:
> > On 26/Jun - 00:23, Gilles Chanteperdrix wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> On 06/25/2014 11:47 AM, Arnaud Degroote wrote:
> >>> On 25/Jun - 10:37, Gilles Chanteperdrix wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>
> >>>> On 06/25/2014 10:11 AM, Arnaud Degroote wrote:
> >>>>> On 24/Jun - 20:31, Gilles Chanteperdrix wrote:
> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>>>
> >>>>>> On 06/24/2014 02:21 PM, Arnaud Degroote wrote:
> >>>>>>> On 24/Jun - 08:29, Gilles Chanteperdrix wrote:
> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>>>>>
> >>>>>>>> On 06/24/2014 08:23 AM, Arnaud Degroote wrote:
> >>>>>>>>> On 24/Jun - 01:45, Gilles Chanteperdrix wrote:
> >>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>>>>>>>
> >>>>>>>>>> On 06/23/2014 01:18 PM, Arnaud Degroote wrote:
> >>>>>>>>>>> On 23/Jun - 11:22, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>> On 06/23/2014 11:08 AM, Arnaud Degroote
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>> Hi list,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm trying to deploy a 3.14 kernel on my
> >>>>>>>>>>>>> BeagleBoard XM rev C but got several
> >>>>>>>>>>>>> issues. So, first question, it is supposed
> >>>>>>>>>>>>> to be supported or am I somewhere in a grey
> >>>>>>>>>>>>> zone ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Let describe more precisely the
> >>>>>>>>>>>>> configuration and the symptom. -
> >>>>>>>>>>>>> linux-ipipe branch ipipe-3.14 - xenomai
> >>>>>>>>>>>>> 2.6.3 + some patches from 2.6 branch
> >>>>>>>>>>>>> (including
> >>>>>>>>>>>>> d1d00e0acd29bb5f9023494a883a7fa0def40917
> >>>>>>>>>>>>> 41cb1f73814d1094e0ea75ccbbd23ff01280787e
> >>>>>>>>>>>>> 7a48019268d7e1157ebb072b88f6683425f0c7c5
> >>>>>>>>>>>>> f00d22eca6277e780c19a5d5ecd2ed0e23dabafe )
> >>>>>>>>>>>>
> >>>>>>>>>>>> It is supposed to work, could you try again
> >>>>>>>>>>>> with the xenomai 2.6 git?
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Gilles,
> >>>>>>>>>>>
> >>>>>>>>>>> I just tested against 2.6-git and observe the
> >>>>>>>>>>> same behaviours.
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>>
> >>>>>>>>>> Could you post your configuration?
> >>>>>>>>>
> >>>>>>>>> Sure, see the attached defconfig. It is basically
> >>>>>>>>> yocto base arm kernel + xenomai (and some kernel
> >>>>>>>>> hacking option).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Could you try to turn off CONFIG_NO_HZ ?
> >>>>>>>
> >>>>>>> Without CONFIG_NO_HZ, it hangs repeatably during the
> >>>>>>> boot (in the same place than with CONFIG_NO_HZ without
> >>>>>>> CONFIG_DEBUG_LOCK_ALLOC, so this last option is more
> >>>>>>> a timing workaround than a "real fix"). See the
> >>>>>>> attached defconfig and boot log.
> >>>>>>
> >>>>>> Do you have the same problem if you boot using NFS
> >>>>>> instead of an SD card?
> >>>>>>
> >>>>>
> >>>>> Using root on nfs does not seem to change the problem. It
> >>>>> still hangs in the same place.
> >>>>
> >>>> Ok, could you disable FTRACE, then enable the I-pipe debugs
> >>>> except the I-pipe tracer? And enable all the xenomai debugs?
> >>>>
> >>>
> >>> Without FTRACE, the kernel seems to boot successfully quite
> >>> often (I won't say always still). Moreover, the clocktest now
> >>> terminates. Still, the latency hangs, without much debug
> >>> information (maybe I miss some options in the kernel
> >>> configuration or at runtime). At this moment,
> >>> /proc/xenomai/sched shows
> >>>
> >>> root at beagleboard:~# cat /proc/xenomai/sched CPU PID CLASS
> >>> PRI TIMEOUT TIMEBASE STAT NAME 0 0 idle -1
> >>> - master R ROOT 0 391 rt 0 - master
> >>> X switchtest 0 392 rt 0 - master X
> >>> switchtest 0 405 rt 0 - master X
> >>> display-393 0 406 rt 99 481us master Dt
> >>> sampling-393 0 0 rt 1 - master Wl
> >>> rtk1/0 0 0 rt 1 - master Wl rtk2/0
> >>> 0 0 rt 1 - master Wlf rtk3/0 0 0
> >>> rt 1 - master Wlf rtk4/0 0 0 rt
> >>> 1 - master Wlf rtk5/0 0 0 rt 1
> >>> - master Wlf rtk6/0 0 0 rt 1 -
> >>> master Wl rtk1/0 0 0 rt 1 - master
> >>> Wl rtk2/0 0 0 rt 1 - master Wlf
> >>> rtk3/0 0 0 rt 1 - master Wlf rtk4/0
> >>> 0 0 rt 1 - master Wlf rtk5/0 0 0
> >>> rt 1 - master Wlf rtk6/0 0 417 rt
> >>> 1 - master Wl rtup0-7 0 419 rt 1
> >>> - master Wl rtup0-7 0 420 rt 1 -
> >>> master Wl rtup0-8 0 421 rt 1 -
> >>> master Wl rtup0-8 0 422 rt 1 -
> >>> master Wl rtup_ufpp0-9 0 423 rt 1 -
> >>> master Wl rtup_ufpp0-9 0 424 rt 1 -
> >>> master Wl rtup_ufpp0-10 0 426 rt 1
> >>> - master Wl rtup_ufpp0-10 0 427 rt 1
> >>> - master X rtus0-11 0 428 rt 1 -
> >>> master X rtus0-11 0 429 rt 1 -
> >>> master X rtus0-12 0 430 rt 1 -
> >>> master X rtus0-12 0 432 rt 1 -
> >>> master X rtus_ufps0-13 0 433 rt 1
> >>> - master X rtus_ufps0-13 0 434 rt 1
> >>> - master X rtus_ufps0-14 0 435 rt 1
> >>> - master X rtus_ufps0-14 0 436 rt 1
> >>> - master X rtuo0-15 0 437 rt 1 -
> >>> master X rtuo0-15 0 438 rt 1 -
> >>> master X rtuo0-16 0 439 rt 1 -
> >>> master X rtuo0-16 0 440 rt 1 -
> >>> master X rtuo_ufpp0-17 0 441 rt 1
> >>> - master X rtuo_ufpp0-17 0 442 rt 1
> >>> - master Wl rtuo_ufpp0-18 0 443 rt 1
> >>> - master X rtuo_ufpp0-18 0 444 rt 1
> >>> - master Wl rtuo_ufps0-19 0 445 rt 1
> >>> - master X rtuo_ufps0-19 0 446 rt 1
> >>> - master Wl rtuo_ufps0-20 0 447 rt 1
> >>> - master X rtuo_ufps0-20 0 448 rt 1
> >>> - master Wl rtuo_ufpp_ufps0-21 0 450 rt
> >>> 1 - master X rtuo_ufpp_ufps0-21 0 451
> >>> rt 1 - master Wl rtuo_ufpp_ufps0-22 0
> >>> 452 rt 1 - master X
> >>> rtuo_ufpp_ufps0-22
> >>
> >> You are not just running latency, you are running latency and
> >> switchtest.
> >>
> >> Could you try and run the latency test alone? Please proceed one
> >> step at a time.
> >
> > Yes, sorry for that, I use xeno-regression-test directly.
> >
> > latency seems to work properly. switchtest with the default
> > argument hangs quite fast. switchtest -s 1000 seems to survive long
> > time.
> >
> > Concerning your previous mail, any easy way to test GP timer I'm
> > not aware about or must I write some kind of test kernel module ?
> >
> If the latency test works, the GP timer works, no need to test it.
>
> switchtest is another story. Does switchtest hang, or does the system
> completely freeze?
switchtest hangs, but the system is still responsive. I can ctrl-c
it and restart it. On C-c, it prints "properly" a number of ctx switches
done (which is far from other "normal" values).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140626/c22ec378/attachment.sig>
More information about the Xenomai
mailing list