On Wed, 2007-08-01 at 11:26 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2007-08-01 at 11:10 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> 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.
> >> The whole issue remains mysterious: None of the Xenomai handlers
> >> involved in the output of "sched" should be able to return EAGAIN. Only
> >> if seq_open returned such error (which it shouldn't according to the
> >> kernel code), this code would be imaginable.
> > 
> > /proc/xenomai/stat is involved, not /sched.
> 
> That doesn't matter, the code pattern is the same.
> 

Bad news, at some point, it does return ENOMEM too. Maybe it's actually
a transient condition on the target. I'll handle this one, since it does
not seem to be reproducible elsewhere.

> Jan
> 
-- 
Philippe.



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

Reply via email to