From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <46B04DEA.6040000@domain.hid> References: <46AF5F1E.7030009@domain.hid> <1185899217.6611.246.camel@domain.hid> <46AF63F8.70207@domain.hid> <1185900471.6611.249.camel@domain.hid> <1185900717.6611.251.camel@domain.hid> <46AF69BC.6030109@domain.hid> <1185902177.6611.253.camel@domain.hid> <46B04DEA.6040000@domain.hid> Content-Type: text/plain Date: Wed, 01 Aug 2007 11:21:34 +0200 Message-Id: <1185960095.6611.263.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: Philippe Gerum Subject: Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core 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.