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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Already a plain command sequence causes this problem:

# modprobe xeno_nucleus
# rmmod xeno_nucleus
rmmod: xeno_nucleus: Resource temporarily unavailable

Can anyone confirm? This is unfortunately only a secondary issue that I
came across while hunting more severe problems of my colleagues, ie. I
don't have the time to look into detail ATM.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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
either, though, but it does happen on the other site.

>  This is unfortunately only a secondary issue that I
> came across while hunting more severe problems of my colleagues, ie. I
> don't have the time to look into detail ATM.
> 
> Jan
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

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
> either, though, but it does happen on the other site.

OK, will look into it again once I found what breaks
xnintr_edge_shirq_handler() here (2.4 and 2.3). Damn it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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.

> > either, though, but it does happen on the other site.
> 
> OK, will look into it again once I found what breaks
> xnintr_edge_shirq_handler() here (2.4 and 2.3). Damn it.
> 

Did somebody tell you about a guy named Sisyphus, already? :o>

> Jan
> 
-- 
Philippe.

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

[Philippe Gerum]

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.
 
-- 
Philippe.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

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. But I would have to re-check this thing
as well. I assume there is no hope for a test case then?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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.

> Jan
> 
-- 
Philippe.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

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
> either, though, but it does happen on the other site.

False alarm: Some forgotten Linux program was waiting on /dev/rtp
devices. Everything's unloading fine again after killing it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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.