On Tue, 2007-07-31 at 18:56 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Tue, 2007-07-31 at 18:47 +0200, Philippe Gerum wrote:
> >> On Tue, 2007-07-31 at 18:31 +0200, Jan Kiszka wrote:
> >>> Philippe Gerum wrote:
> >>>> On Tue, 2007-07-31 at 18:11 +0200, Jan Kiszka wrote:
> >>>>> Already a plain command sequence causes this problem:
> >>>>>
> >>>>> # modprobe xeno_nucleus
> >>>>> # rmmod xeno_nucleus
> >>>>> rmmod: xeno_nucleus: Resource temporarily unavailable
> >>>>>
> >>>>> Can anyone confirm?
> >>>> Cannot reproduce it here. However, I got another report saying that
> >>>> /proc/xenomai/stat would return -ENOMEM. Cannot reproduce it here
> >> Correction: it would return -EAGAIN, so maybe the status leaks when a
> >> restart condition has been encountered in the stat loop. Seems minor,
> >> compared to ENOMEM.
> >>
> > 
> > Btw, you will likely need a large number of threads to make this happen
> > (~40), at least this is the case for the reporting site.
> >  
> 
> I think you need a large number of _fluctuating_ threads, as EAGAIN
> should only be returned if something (thread count, IRQ assignments)
> changes while dumping the list.

This was implied.

>  But I would have to re-check this thing
> as well. I assume there is no hope for a test case then?
> 

Nope.

> Jan
> 
-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to