Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote:
> > > BTW, with latest SVN trunk and scalable sched, the oopses are gone but
> > > latency still doesn't start up:
> > >
> > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/sched
> > > CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
> > > 0 0 -1 0 0 master R ROOT
> > > 0 930 0 0 0 master R
> display-928
> > > 0 931 99 0 0 master R
> sampling-928
> > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat
> > > CPU PID MSW CSW PF STAT %CPU NAME
> > > 0 0 0 0 0 00500080 100.0 ROOT
> > > 0 930 0 0 0 00300188 0.0 display-928
> > > 0 931 0 0 0 00300188 0.0 sampling-928
> >
> > Two threads in ready state with higher priority than the root one: this
> > means that a rescheduling opportunity has been missed, or more
> > precisely, someone may be lying to xnpod_schedule() wrt to priority
> > ordering when the scalable sched is enabled.
>
> ffsmlq uses ffnz, and there are two implementations of ffnz, one in
> asm/hal.h which is correct on x86_64, the other in nucleus/system.h
> which uses ffs hence only operates on ints.
Never mind, nucleus/system.h is only included when using Xenomai headers
in user-space. Nevertheless, it should probably use ffsl instead of ffs.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
