[Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Brian L.]

I apologize for not including the panic here. I will be obtaining a
serial cable tomorrow and accessing panic text should become much
simpler. Since the panic is several screen-fulls long, even if I were
to painstakingly type it in, it would be missing vital information.

I'm posting this now in case this is a known issue with a simple fix.
Newsgroup history doesn't turn up any messages with rt_queue_create
and panic in the past few months. I am running xenomai 2.1.0 on linux
2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.

Code:
======
int main() {
RT_TASK main_task;
RT_QUEUE queue;
RT_MUTEX lock;

if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
   die("Couldn't Shadow Main Task\n");
}

rt_mutex_create(&lock,0);
rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
...
}
======

The kernel panics and freezes the test machine in rt_queue_create. I
will post panic text as soon as it is accessible to me. The panic
occurs whether or not I shadow the main task and whether or not the
mutex is named. Am I misusing an API or am I possibly looking at a
bug?

The bottom 25 lines of the panic seem to involve a call to the ipipe
exception handler every 6-8 lines. It doesn't look like endless
recursion, though, so we could just be walking up an exception tree.
I'm missing the top of the trace and the panic type because it doesn't
get logged and I can't scroll a frozen machine.

Thanks,

Brian

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Philippe Gerum]

Brian L. wrote:
> I apologize for not including the panic here. I will be obtaining a
> serial cable tomorrow and accessing panic text should become much
> simpler. Since the panic is several screen-fulls long, even if I were
> to painstakingly type it in, it would be missing vital information.
> 
> I'm posting this now in case this is a known issue with a simple fix.
> Newsgroup history doesn't turn up any messages with rt_queue_create
> and panic in the past few months. I am running xenomai 2.1.0 on linux
> 2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.
> 
> Code:
> ======
> int main() {
> RT_TASK main_task;
> RT_QUEUE queue;
> RT_MUTEX lock;
> 

    mlockall(MCL_CURRENT|...) ?

> if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
>    die("Couldn't Shadow Main Task\n");
> }
> 
> rt_mutex_create(&lock,0);
> rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
> ...
> }
> ======
> 
> The kernel panics and freezes the test machine in rt_queue_create. I
> will post panic text as soon as it is accessible to me. The panic
> occurs whether or not I shadow the main task and whether or not the
> mutex is named. Am I misusing an API or am I possibly looking at a
> bug?
> 
> The bottom 25 lines of the panic seem to involve a call to the ipipe
> exception handler every 6-8 lines. It doesn't look like endless
> recursion, though, so we could just be walking up an exception tree.
> I'm missing the top of the trace and the panic type because it doesn't
> get logged and I can't scroll a frozen machine.
> 
> Thanks,
> 
> Brian
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Jan Kiszka]

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

Philippe Gerum wrote:
> Brian L. wrote:
>> I apologize for not including the panic here. I will be obtaining a
>> serial cable tomorrow and accessing panic text should become much
>> simpler. Since the panic is several screen-fulls long, even if I were
>> to painstakingly type it in, it would be missing vital information.
>>
>> I'm posting this now in case this is a known issue with a simple fix.
>> Newsgroup history doesn't turn up any messages with rt_queue_create
>> and panic in the past few months. I am running xenomai 2.1.0 on linux
>> 2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.
>>
>> Code:
>> ======
>> int main() {
>> RT_TASK main_task;
>> RT_QUEUE queue;
>> RT_MUTEX lock;
>>
> 
>    mlockall(MCL_CURRENT|...) ?

Would this excuse the panic?

> 
>> if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
>>    die("Couldn't Shadow Main Task\n");
>> }
>>
>> rt_mutex_create(&lock,0);
>> rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
>> ...
>> }
>> ======
>>
>> The kernel panics and freezes the test machine in rt_queue_create. I
>> will post panic text as soon as it is accessible to me. The panic
>> occurs whether or not I shadow the main task and whether or not the
>> mutex is named. Am I misusing an API or am I possibly looking at a
>> bug?
>>
>> The bottom 25 lines of the panic seem to involve a call to the ipipe
>> exception handler every 6-8 lines. It doesn't look like endless
>> recursion, though, so we could just be walking up an exception tree.
>> I'm missing the top of the trace and the panic type because it doesn't
>> get logged and I can't scroll a frozen machine.
>>
>> Thanks,
>>
>> Brian
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
> 
> 



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

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Brian L.]

How could I forget mlockall? I've been calling it in rtai forever...Is
there any other neccessary boilerplate?

...unfortunately that didn't solve the problem and probably shouldn't,
being that the machine has swap disabled.

I'll get to work on getting the traceback...I build the kernel with
frame pointers overnight, so once I have the serial hardware together,
I'll be good to go.

Jan: I would hope that forgetting that call couldn't ever result in a panic.







On 4/4/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> Philippe Gerum wrote:
> > Brian L. wrote:
> >> I apologize for not including the panic here. I will be obtaining a
> >> serial cable tomorrow and accessing panic text should become much
> >> simpler. Since the panic is several screen-fulls long, even if I were
> >> to painstakingly type it in, it would be missing vital information.
> >>
> >> I'm posting this now in case this is a known issue with a simple fix.
> >> Newsgroup history doesn't turn up any messages with rt_queue_create
> >> and panic in the past few months. I am running xenomai 2.1.0 on linux
> >> 2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.
> >>
> >> Code:
> >> ======
> >> int main() {
> >> RT_TASK main_task;
> >> RT_QUEUE queue;
> >> RT_MUTEX lock;
> >>
> >
> >    mlockall(MCL_CURRENT|...) ?
>
> Would this excuse the panic?
>
> >
> >> if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
> >>    die("Couldn't Shadow Main Task\n");
> >> }
> >>
> >> rt_mutex_create(&lock,0);
> >> rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
> >> ...
> >> }
> >> ======
> >>
> >> The kernel panics and freezes the test machine in rt_queue_create. I
> >> will post panic text as soon as it is accessible to me. The panic
> >> occurs whether or not I shadow the main task and whether or not the
> >> mutex is named. Am I misusing an API or am I possibly looking at a
> >> bug?
> >>
> >> The bottom 25 lines of the panic seem to involve a call to the ipipe
> >> exception handler every 6-8 lines. It doesn't look like endless
> >> recursion, though, so we could just be walking up an exception tree.
> >> I'm missing the top of the trace and the panic type because it doesn't
> >> get logged and I can't scroll a frozen machine.
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> _______________________________________________
> >> Xenomai-help mailing list
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >>
> >
> >
>
>
>
>
>

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Jan Kiszka]

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

Brian L. wrote:
> How could I forget mlockall? I've been calling it in rtai forever...Is
> there any other neccessary boilerplate?

This is a very frequently made mistake. Philippe, is there a chance add
some simple debug check for this situation? Something to check when the
first shadow thread is created for a process?

Jan


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

[Xenomai-core] Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Philippe Gerum]

Jan Kiszka wrote:
> Brian L. wrote:
> 
>>How could I forget mlockall? I've been calling it in rtai forever...Is
>>there any other neccessary boilerplate?
> 
> 
> This is a very frequently made mistake. Philippe, is there a chance add
> some simple debug check for this situation? Something to check when the
> first shadow thread is created for a process?

The following patch would cause SIGXCPU to be sent to emerging real-time 
threads from a non-fully mlocked program (i.e. not including 
MCL_FUTURE). We should make this conditionally compiled too. I'm not 
sure that we would not introduce problems when dealing with mmio areas 
mapped in user-space at least for older kernel revisions (the VM_IO 
issue might have been fixed in recent kernels, though), this is why I 
would tend to make it easy to work around this check by simply ignoring 
the signal, for handling specific init configurations for which people 
know what they are doing.

--- ksrc/nucleus/shadow.c	(revision 875)
+++ ksrc/nucleus/shadow.c	(working copy)
@@ -754,6 +754,9 @@
  		    current->pid,
  		    xnthread_base_priority(thread));

+    if (!(current->mm->def_flags & VM_LOCKED))
+	send_sig(SIGXCPU,current,1);
+
      current->cap_effective |=
  	CAP_TO_MASK(CAP_IPC_LOCK)|
  	CAP_TO_MASK(CAP_SYS_RAWIO)|

-- 

Philippe.

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Brian L. wrote:
>>
>>>I apologize for not including the panic here. I will be obtaining a
>>>serial cable tomorrow and accessing panic text should become much
>>>simpler. Since the panic is several screen-fulls long, even if I were
>>>to painstakingly type it in, it would be missing vital information.
>>>
>>>I'm posting this now in case this is a known issue with a simple fix.
>>>Newsgroup history doesn't turn up any messages with rt_queue_create
>>>and panic in the past few months. I am running xenomai 2.1.0 on linux
>>>2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.
>>>
>>>Code:
>>>======
>>>int main() {
>>>RT_TASK main_task;
>>>RT_QUEUE queue;
>>>RT_MUTEX lock;
>>>
>>
>>   mlockall(MCL_CURRENT|...) ?
> 
> 
> Would this excuse the panic?
> 

I would expect the thread to be relaxed by Xeno so that the fixup and 
later paging in happen properly, but given the few bits given here, I'm 
trying to rule out unexpected page faulting issues.

> 
>>>if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
>>>   die("Couldn't Shadow Main Task\n");
>>>}
>>>
>>>rt_mutex_create(&lock,0);
>>>rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
>>>...
>>>}
>>>======
>>>
>>>The kernel panics and freezes the test machine in rt_queue_create. I
>>>will post panic text as soon as it is accessible to me. The panic
>>>occurs whether or not I shadow the main task and whether or not the
>>>mutex is named. Am I misusing an API or am I possibly looking at a
>>>bug?
>>>
>>>The bottom 25 lines of the panic seem to involve a call to the ipipe
>>>exception handler every 6-8 lines. It doesn't look like endless
>>>recursion, though, so we could just be walking up an exception tree.
>>>I'm missing the top of the trace and the panic type because it doesn't
>>>get logged and I can't scroll a frozen machine.
>>>
>>>Thanks,
>>>
>>>Brian
>>>
>>>_______________________________________________
>>>Xenomai-help mailing list
>>>Xenomai-help@domain.hid
>>>https://mail.gna.org/listinfo/xenomai-help
>>>
>>
>>
> 
> 


-- 

Philippe.

Re: [Xenomai-help] Panic in rt_queue_create: bug or misuse?

[Philippe Gerum]

Brian L. wrote:
> I apologize for not including the panic here. I will be obtaining a
> serial cable tomorrow and accessing panic text should become much
> simpler. Since the panic is several screen-fulls long, even if I were
> to painstakingly type it in, it would be missing vital information.
> 
> I'm posting this now in case this is a known issue with a simple fix.
> Newsgroup history doesn't turn up any messages with rt_queue_create
> and panic in the past few months. I am running xenomai 2.1.0 on linux
> 2.6.15 with APIC disabled in kernel config on a celeron 566/440bx.
> 
> Code:
> ======
> int main() {
> RT_TASK main_task;
> RT_QUEUE queue;
> RT_MUTEX lock;
> 
> if (0 != rt_task_shadow(&main_task,"MAIN",1,T_FPU)) {
>    die("Couldn't Shadow Main Task\n");
> }
> 
> rt_mutex_create(&lock,0);
> rt_queue_create(&queue,"log_queue",8192,100,Q_FIFO);
> ...
> }
> ======
> 
> The kernel panics and freezes the test machine in rt_queue_create. I
> will post panic text as soon as it is accessible to me. The panic
> occurs whether or not I shadow the main task and whether or not the
> mutex is named. Am I misusing an API or am I possibly looking at a
> bug?

No API misuse should cause a crash anyway. I cannot reproduce the issue 
locally by just copy/pasting the code fragment above; does this exact 
code alone crash your box?

> 
> The bottom 25 lines of the panic seem to involve a call to the ipipe
> exception handler every 6-8 lines. It doesn't look like endless
> recursion, though, so we could just be walking up an exception tree.
> I'm missing the top of the trace and the panic type because it doesn't
> get logged and I can't scroll a frozen machine.
> 
> Thanks,
> 
> Brian
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.