Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded

[Philippe Gerum <rpm@xenomai.org>]

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.

> 
> Jan
> 
-- 
Philippe.