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