Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] 2.4-rc1: modular nucleus cannot be unloaded
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
