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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to