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.

Jan