[Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Kaeppeler, Oliver]

[-- Attachment #1.1: Type: text/plain, Size: 1223 bytes --]

Hello,
 
we get an frozen system, if we start a multi-threaded posix-skin
application within the GNU-Debugger (gdb) on an Intel dual core
processor. Precisely, the system freezes when threads are being created.
Often the problem occurs when the third or fourth thread is being
created.
 
Some further remarks:
o We use OpenSUSE Linux 10.3 and Xenomai 2.4.3 over Linux Vanilla
2.6.24.5. Xenomai 2.4.0 over 2.6.23.9 shows simular behavier.
o Toolchain SUSE 10.3 as is.  
o We run "init 3", so no x-server
o We tested some gdb-Versions (6.3, 6.6, 6.8), but the result remains
the same.
o The system does NOT freeze, if the dual core feature is deactivated in
the BIOS (so the processor works just with ONE core)!
o Without gdb the program runs as expected.
 
We attached a very small example program that creates 50 threads via
pthread_create(). Each thread prints "Hello world", sleeps a few seconds
and exits. We also attached the result of xeno-test (xeno-test.log.bz2)
and /proc/config.gz.
 
To start the application "test1" within the debugger, just type the
following:
# gdb test1
(gdb) run
 
Does anybody know, why the system freezes?
Thanks in advance!
Oliver Kaeppeler.
 
 
 
 
 

[-- Attachment #1.2: Type: text/html, Size: 2608 bytes --]

[-- Attachment #2: test1.tar.bz2 --]
[-- Type: application/octet-stream, Size: 4940 bytes --]

[-- Attachment #3: xeno-test.log.bz2 --]
[-- Type: application/octet-stream, Size: 13450 bytes --]

[-- Attachment #4: config.gz --]
[-- Type: application/x-gzip, Size: 21589 bytes --]

Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Jan Kiszka]

Kaeppeler, Oliver wrote:
> Hello,
>  
> we get an frozen system, if we start a multi-threaded posix-skin
> application within the GNU-Debugger (gdb) on an Intel dual core
> processor. Precisely, the system freezes when threads are being created.
> Often the problem occurs when the third or fourth thread is being
> created.
>  
> Some further remarks:
> o We use OpenSUSE Linux 10.3 and Xenomai 2.4.3 over Linux Vanilla
> 2.6.24.5. Xenomai 2.4.0 over 2.6.23.9 shows simular behavier.
> o Toolchain SUSE 10.3 as is.  
> o We run "init 3", so no x-server
> o We tested some gdb-Versions (6.3, 6.6, 6.8), but the result remains
> the same.
> o The system does NOT freeze, if the dual core feature is deactivated in
> the BIOS (so the processor works just with ONE core)!
> o Without gdb the program runs as expected.
>  
> We attached a very small example program that creates 50 threads via
> pthread_create(). Each thread prints "Hello world", sleeps a few seconds
> and exits. We also attached the result of xeno-test (xeno-test.log.bz2)
> and /proc/config.gz.
>  
> To start the application "test1" within the debugger, just type the
> following:
> # gdb test1
> (gdb) run
>  
> Does anybody know, why the system freezes?

Yep. Known issue. Already fixed in latest SVN trunk and 2.4.x.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

Hello,

I try to manage irq on my digital I/O board rtdm driver.
So, I call rtdm_irq_request with RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE
option to define my irq handler, in my rtdm open function.
This irq handler works very good.
So, I try to establish a callback system to inform my sofware when an
valid interrupt is arrived.
I don't know callback system, so i establish a rtdm semaphore.
So, in my irq handler I call rtdm_sem_up, and I have an blocant ioctl
where I call only rtdm_sem_down.

To test this method, I write a test code, where I create a rt task by
calling rt_task_create(&Handler_IT_task, "Handler IT Task",0,50,0); and
rt_task_start(&Handler_IT_task, &Handler_IT_task_proc, NULL);

And my task procedure is :

void Handler_IT_task_proc (void * arg)
{
	int ret;
	while(1)
	{
		ret = rt_dev_ioctl(IO_Card_ID, DISCRETS_IOC_WAIT_IT, 0);
		if (!ret)
			printf("IT detected\n");
		else
			goto exit_Handler_IT_task;
		//rt_task_suspend(&Handler_IT_task);
	}
exit_Handler_IT_task:
	printf("Exit Handler IT task\n");
}

My problem is that on IT reception, my work station freeze. But, if I
call a suspend task after my blocant ioctl (see comment), and I call an
task resume by a gets in my main function, all my interrupts are founded
correctly.

I try to change the rtdm semaphore by a rtdm event, but the results are
the same.

So, why my sofware is frozen when the Handler task procedure keep the
hand ? Can I establish a really callback function instead of a blocant
ioctl ?

Tanks.

Guillaume Dournes.

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

[ Please don't reply on earlier postings when starting a new thread. ]

DOURNES Guillaume wrote:
> Hello,
> 
> I try to manage irq on my digital I/O board rtdm driver.
> So, I call rtdm_irq_request with RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE
> option to define my irq handler, in my rtdm open function.
> This irq handler works very good.
> So, I try to establish a callback system to inform my sofware when an
> valid interrupt is arrived.
> I don't know callback system, so i establish a rtdm semaphore.
> So, in my irq handler I call rtdm_sem_up, and I have an blocant ioctl
> where I call only rtdm_sem_down.
> 
> To test this method, I write a test code, where I create a rt task by
> calling rt_task_create(&Handler_IT_task, "Handler IT Task",0,50,0); and
> rt_task_start(&Handler_IT_task, &Handler_IT_task_proc, NULL);
> 
> And my task procedure is :
> 
> void Handler_IT_task_proc (void * arg)
> {
> 	int ret;
> 	while(1)
> 	{
> 		ret = rt_dev_ioctl(IO_Card_ID, DISCRETS_IOC_WAIT_IT, 0);
> 		if (!ret)
> 			printf("IT detected\n");
> 		else
> 			goto exit_Handler_IT_task;
> 		//rt_task_suspend(&Handler_IT_task);
> 	}
> exit_Handler_IT_task:
> 	printf("Exit Handler IT task\n");
> }
> 
> My problem is that on IT reception, my work station freeze. But, if I
> call a suspend task after my blocant ioctl (see comment), and I call an
> task resume by a gets in my main function, all my interrupts are founded
> correctly.
> 
> I try to change the rtdm semaphore by a rtdm event, but the results are
> the same.
> 
> So, why my sofware is frozen when the Handler task procedure keep the
> hand ? Can I establish a really callback function instead of a blocant
> ioctl ?

Use CONFIG_XENO_OPT_WATCHDOG to ensure that you don't see a runaway
thread here. Alternatively, you could break out of the loop after some
iterations to check if this is the reason for your "locked-up" system.

Note that, if we should help you beyond this, we will need the driver
source code as well. How should we know otherwise when your driver
returns 0 and how long it suspends the caller?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

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

I join to this mail my source code of my driver and my test software. The read and write function of this driver version are already tested, and work as waiting.

I tried to break out the loop. If I break out after 1 loop, the software works, but if I break out after 2 loops, the sofware freeze and the result (printf) of the first loop is not printed.

For my test, the interrupt is generated every 10 secondes, but in fact for my real software the interrupt will be generated every 5ms.
 

-----Message d'origine-----
De : Jan Kiszka [mailto:jan.kiszka@domain.hid
Envoyé : mardi 13 mai 2008 13:03
À : DOURNES Guillaume
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] Interrupt management under rtdm driver

[ Please don't reply on earlier postings when starting a new thread. ]

DOURNES Guillaume wrote:
> Hello,
> 
> I try to manage irq on my digital I/O board rtdm driver.
> So, I call rtdm_irq_request with RTDM_IRQTYPE_SHARED | 
> RTDM_IRQTYPE_EDGE option to define my irq handler, in my rtdm open function.
> This irq handler works very good.
> So, I try to establish a callback system to inform my sofware when an 
> valid interrupt is arrived.
> I don't know callback system, so i establish a rtdm semaphore.
> So, in my irq handler I call rtdm_sem_up, and I have an blocant ioctl 
> where I call only rtdm_sem_down.
> 
> To test this method, I write a test code, where I create a rt task by 
> calling rt_task_create(&Handler_IT_task, "Handler IT Task",0,50,0); 
> and rt_task_start(&Handler_IT_task, &Handler_IT_task_proc, NULL);
> 
> And my task procedure is :
> 
> void Handler_IT_task_proc (void * arg) {
> 	int ret;
> 	while(1)
> 	{
> 		ret = rt_dev_ioctl(IO_Card_ID, DISCRETS_IOC_WAIT_IT, 0);
> 		if (!ret)
> 			printf("IT detected\n");
> 		else
> 			goto exit_Handler_IT_task;
> 		//rt_task_suspend(&Handler_IT_task);
> 	}
> exit_Handler_IT_task:
> 	printf("Exit Handler IT task\n");
> }
> 
> My problem is that on IT reception, my work station freeze. But, if I 
> call a suspend task after my blocant ioctl (see comment), and I call 
> an task resume by a gets in my main function, all my interrupts are 
> founded correctly.
> 
> I try to change the rtdm semaphore by a rtdm event, but the results 
> are the same.
> 
> So, why my sofware is frozen when the Handler task procedure keep the 
> hand ? Can I establish a really callback function instead of a blocant 
> ioctl ?

Use CONFIG_XENO_OPT_WATCHDOG to ensure that you don't see a runaway thread here. Alternatively, you could break out of the loop after some iterations to check if this is the reason for your "locked-up" system.

Note that, if we should help you beyond this, we will need the driver source code as well. How should we know otherwise when your driver returns 0 and how long it suspends the caller?

Jan

--
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux


[-- Attachment #2: V02R00.rar --]
[-- Type: application/octet-stream, Size: 45369 bytes --]

Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Kaeppeler, Oliver]

Hello Jan,

thanks for your answer. We had used Xenomai 2.4.3 in our tests. Now, I also tried the daily snapshot version, but the problem remains.

The problem should be reproducable by the sample program, we attached in our last message...

Regards,
Oliver.
 

-----Ursprüngliche Nachricht-----
Von: Jan Kiszka [mailto:jan.kiszka@domain.hid
Gesendet: Dienstag, 13. Mai 2008 11:37
An: Kaeppeler, Oliver
Cc: xenomai@xenomai.org
Betreff: Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

Kaeppeler, Oliver wrote:
> Hello,
>  
> we get an frozen system, if we start a multi-threaded posix-skin 
> application within the GNU-Debugger (gdb) on an Intel dual core 
> processor. Precisely, the system freezes when threads are being created.
> Often the problem occurs when the third or fourth thread is being 
> created.
>  
> Some further remarks:
> o We use OpenSUSE Linux 10.3 and Xenomai 2.4.3 over Linux Vanilla 
> 2.6.24.5. Xenomai 2.4.0 over 2.6.23.9 shows simular behavier.
> o Toolchain SUSE 10.3 as is.  
> o We run "init 3", so no x-server
> o We tested some gdb-Versions (6.3, 6.6, 6.8), but the result remains 
> the same.
> o The system does NOT freeze, if the dual core feature is deactivated 
> in the BIOS (so the processor works just with ONE core)!
> o Without gdb the program runs as expected.
>  
> We attached a very small example program that creates 50 threads via 
> pthread_create(). Each thread prints "Hello world", sleeps a few 
> seconds and exits. We also attached the result of xeno-test 
> (xeno-test.log.bz2) and /proc/config.gz.
>  
> To start the application "test1" within the debugger, just type the
> following:
> # gdb test1
> (gdb) run
>  
> Does anybody know, why the system freezes?

Yep. Known issue. Already fixed in latest SVN trunk and 2.4.x.

Jan

--
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux

Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Jan Kiszka]

Kaeppeler, Oliver wrote:
> Hello Jan,
> 
> thanks for your answer. We had used Xenomai 2.4.3 in our tests. Now, I also tried the daily snapshot version, but the problem remains.
> 
> The problem should be reproducable by the sample program, we attached in our last message...

OK, will give this a try later today.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

DOURNES Guillaume wrote:
> ***********************
> Warning: Your file, V02R00.rar, contains more than 32 files after decompression and cannot be scanned.
> ***********************
> 
> 
> I join to this mail my source code of my driver and my test software. The read and write function of this driver version are already tested, and work as waiting.
> 
> I tried to break out the loop. If I break out after 1 loop, the software works, but if I break out after 2 loops, the sofware freeze and the result (printf) of the first loop is not printed.

Didn't have to time to unpack your archive (is the driver so complex?).
So you may try to continue with debugging: Does the watchdog catch
something? Is there something on the kernel console after lockup. If
not, attach a serial line and redirect the console to it. Maybe you see
an oops.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

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

Sorry my old archive contained svn files. I send again my cource code.

I have some syslog message as kernel : Oops : 0000 [#1], or kernel : CPU : 0, or EIP : 0060 [<f8a88de7>] Tainted : PF  VLI, etc.

I don't understand the watchdog catch. Can you explain a little more ?

Guillaume.


-----Message d'origine-----
De : xenomai-help-bounces@domain.hid [mailto:xenomai-help-bounces@domain.hid] De la part de Jan Kiszka
Envoyé : mardi 13 mai 2008 16:48
À : DOURNES Guillaume
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] Interrupt management under rtdm driver

DOURNES Guillaume wrote:
> ***********************
> Warning: Your file, V02R00.rar, contains more than 32 files after decompression and cannot be scanned.
> ***********************
> 
> 
> I join to this mail my source code of my driver and my test software. The read and write function of this driver version are already tested, and work as waiting.
> 
> I tried to break out the loop. If I break out after 1 loop, the software works, but if I break out after 2 loops, the sofware freeze and the result (printf) of the first loop is not printed.

Didn't have to time to unpack your archive (is the driver so complex?).
So you may try to continue with debugging: Does the watchdog catch something? Is there something on the kernel console after lockup. If not, attach a serial line and redirect the console to it. Maybe you see an oops.

Jan

--
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux

_______________________________________________
Xenomai-help mailing list
Xenomai-help@domain.hid
https://mail.gna.org/listinfo/xenomai-help


[-- Attachment #2: V02R00.rar --]
[-- Type: application/octet-stream, Size: 32154 bytes --]

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

DOURNES Guillaume wrote:
> Sorry my old archive contained svn files. I send again my cource code.
> 
> I have some syslog message as kernel : Oops : 0000 [#1], or kernel : CPU : 0, or EIP : 0060 [<f8a88de7>] Tainted : PF  VLI, etc.

Well, if your system locks up while the test runs, it is not likely that
any message is pushed to syslog anymore. At best you see something on
the console (VGA or serial).

> 
> I don't understand the watchdog catch. Can you explain a little more ?

See the help in the kernel configuration: If the the watchdog catches
some spinning Xenomai thread, it will suspend it, allowing the rest of
the system to run again. This will also generate a log message on the
kernel console.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Jan Kiszka]

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

Jan Kiszka wrote:
> Kaeppeler, Oliver wrote:
>> Hello Jan,
>>
>> thanks for your answer. We had used Xenomai 2.4.3 in our tests. Now, I also tried the daily snapshot version, but the problem remains.
>>
>> The problem should be reproducable by the sample program, we attached in our last message...
> 
> OK, will give this a try later today.

Done, but so far without success, even with your .config. Are you sure
that you booted the right kernel after the update (and that the update
actually contained the fix)?

Jan


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

Re: [Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

Since I add the watchdog option in my kernel configuration, The software doesn't block.
But I obtain an EPREM (-1) error on the second call of rtdm_event_timedwait, and in dmesg : Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:919 (!xnpod_unblockable_p()).
I don't understand why I have this error, because the rtdm_event_timedwait is used as the 16550A rtserial rtdm driver. And I use this rtserial driver, and it works.
Note that this problem doesn't appears when I call rt_task_suspend just after my rtdm_event_timedwait, and I resume the task by a gets.

-----Message d'origine-----
De : Jan Kiszka [mailto:jan.kiszka@domain.hid
Envoyé : mardi 13 mai 2008 18:59
À : DOURNES Guillaume
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] Interrupt management under rtdm driver

DOURNES Guillaume wrote:
> Sorry my old archive contained svn files. I send again my cource code.
> 
> I have some syslog message as kernel : Oops : 0000 [#1], or kernel : CPU : 0, or EIP : 0060 [<f8a88de7>] Tainted : PF  VLI, etc.

Well, if your system locks up while the test runs, it is not likely that any message is pushed to syslog anymore. At best you see something on the console (VGA or serial).

> 
> I don't understand the watchdog catch. Can you explain a little more ?

See the help in the kernel configuration: If the the watchdog catches some spinning Xenomai thread, it will suspend it, allowing the rest of the system to run again. This will also generate a log message on the kernel console.

Jan

--
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux

Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

[Kaeppeler, Oliver]

Hello Jan,

thanks for testing. We fixed the problem now.

The problem was that we used the daily snapshot of trunk (http://svn.gna.org/daily/xenomai-snapshot.tar.gz - the bottom most link on https://gna.org/svn/?group=xenomai named "Sourcecode Daily Snapshot"), which does not contain the fix.
Now we patched it manually based on the patch given in "[Xenomai-core][PATCH] avoid deadlock-prone sighand_lock in do_schedule_event" and everything runs fine.

So obviously http://svn.gna.org/daily/xenomai-snapshot.tar.gz doesn't really contain the current trunk.

Regards,
Oliver.
 

-----Ursprüngliche Nachricht-----
Von: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
Gesendet: Mittwoch, 14. Mai 2008 08:14
An: Kaeppeler, Oliver
Cc: xenomai@xenomai.org
Betreff: Re: [Xenomai-help] gdb + multi-threaded application + Intel dual core processor + Xenomai => frozen system

Jan Kiszka wrote:
> Kaeppeler, Oliver wrote:
>> Hello Jan,
>>
>> thanks for your answer. We had used Xenomai 2.4.3 in our tests. Now, I also tried the daily snapshot version, but the problem remains.
>>
>> The problem should be reproducable by the sample program, we attached in our last message...
> 
> OK, will give this a try later today.

Done, but so far without success, even with your .config. Are you sure that you booted the right kernel after the update (and that the update actually contained the fix)?

Jan

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

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

DOURNES Guillaume wrote:
> Since I add the watchdog option in my kernel configuration, The software doesn't block.
> But I obtain an EPREM (-1) error on the second call of rtdm_event_timedwait, and in dmesg : Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:919 (!xnpod_unblockable_p()).

See, that is interesting.

> I don't understand why I have this error, because the rtdm_event_timedwait is used as the 16550A rtserial rtdm driver. And I use this rtserial driver, and it works.
> Note that this problem doesn't appears when I call rt_task_suspend just after my rtdm_event_timedwait, and I resume the task by a gets.

After having a look at your driver source meanwhile, the problem is that
you register your IOCTL handler also for handling invocation from non-RT
(precisely: "secondary") context. But rtdm_event_timedwait always
requires primary (RT) context. That is something you either have to
check in the IOCTL handler before trying to block a caller - or you
simply do not register for nrt_ioctl (or use a different handler for the
set of IOCTLs in that context).

The reason that suspending the caller made this issue go away was that
you have several plain Linux services in your RT loop that switches the
caller automatically to secondary mode. Thus the first IOCTL succeeded,
but the second failed after re-entering it now as a plain Linux caller.

HTH,
Jan


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

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

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

Jan Kiszka wrote:
> DOURNES Guillaume wrote:
>> Since I add the watchdog option in my kernel configuration, The software doesn't block.
>> But I obtain an EPREM (-1) error on the second call of rtdm_event_timedwait, and in dmesg : Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:919 (!xnpod_unblockable_p()).
> 
> See, that is interesting.
> 
>> I don't understand why I have this error, because the rtdm_event_timedwait is used as the 16550A rtserial rtdm driver. And I use this rtserial driver, and it works.
>> Note that this problem doesn't appears when I call rt_task_suspend just after my rtdm_event_timedwait, and I resume the task by a gets.
> 
> After having a look at your driver source meanwhile, the problem is that
> you register your IOCTL handler also for handling invocation from non-RT
> (precisely: "secondary") context. But rtdm_event_timedwait always
> requires primary (RT) context. That is something you either have to
> check in the IOCTL handler before trying to block a caller - or you
> simply do not register for nrt_ioctl (or use a different handler for the
> set of IOCTLs in that context).
> 
> The reason that suspending the caller made this issue go away was that
> you have several plain Linux services in your RT loop that switches the
> caller automatically to secondary mode. Thus the first IOCTL succeeded,
> but the second failed after re-entering it now as a plain Linux caller.

...But suspending the thread shortly before IOCTL re-entry automatically
switch it back into the right (==RT) context.

Jan


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

Re: [Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

Thanks a lot for your attention. And sorry for my poor english.
I change my context into a real RT context and my problem disappears.

Nevertheless, I have other questions about the IRQ management.

In fact, after executing my software application (so after the rtdm_close call, and so the free irq), I obtain a syslog message : kernel Disabling IRQ #11. This message doesn't affect my software if I run it again, but may be there are some side effect. In dmesg, the following error message appears : irq 11: nobody cared (try booting with the "irqpoll" option).
In my open function I call : 
- request_region
- rtdm_irq_request
In my close function I call :
- rtdm_irq_free
- release_region
May be there is a function to call to avoid this disabling irq ?


Moreover, when I'm using my discrets I/O driver (on the IRQ 11) and I add an USB Key (on this IRQ 11) the software freeze. Note that my USB Key works normaly before I call my open function, and doesn't work after my software execution, may be because of the Disabling IRQ.
Note that the freeze appears with the 16550A rtdm driver use. For example, when my keyboard irq is the same as the seria board irq, the computer freeze when the driver is running and the keyboard is using at the same moment.
I think that the linux irq and xenomai irq are not usable at the same time !

Note that my kernel is configured with shared interrupt.

Guillaume.


-----Message d'origine-----
De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
Envoyé : mercredi 14 mai 2008 21:35
À : DOURNES Guillaume
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] Interrupt management under rtdm driver

Jan Kiszka wrote:
> DOURNES Guillaume wrote:
>> Since I add the watchdog option in my kernel configuration, The software doesn't block.
>> But I obtain an EPREM (-1) error on the second call of rtdm_event_timedwait, and in dmesg : Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:919 (!xnpod_unblockable_p()).
> 
> See, that is interesting.
> 
>> I don't understand why I have this error, because the rtdm_event_timedwait is used as the 16550A rtserial rtdm driver. And I use this rtserial driver, and it works.
>> Note that this problem doesn't appears when I call rt_task_suspend just after my rtdm_event_timedwait, and I resume the task by a gets.
> 
> After having a look at your driver source meanwhile, the problem is 
> that you register your IOCTL handler also for handling invocation from 
> non-RT
> (precisely: "secondary") context. But rtdm_event_timedwait always 
> requires primary (RT) context. That is something you either have to 
> check in the IOCTL handler before trying to block a caller - or you 
> simply do not register for nrt_ioctl (or use a different handler for 
> the set of IOCTLs in that context).
> 
> The reason that suspending the caller made this issue go away was that 
> you have several plain Linux services in your RT loop that switches 
> the caller automatically to secondary mode. Thus the first IOCTL 
> succeeded, but the second failed after re-entering it now as a plain Linux caller.

...But suspending the thread shortly before IOCTL re-entry automatically switch it back into the right (==RT) context.

Jan

Re: [Xenomai-help] Interrupt management under rtdm driver

[Jan Kiszka]

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

DOURNES Guillaume wrote:
> Thanks a lot for your attention. And sorry for my poor english.
> I change my context into a real RT context and my problem disappears.
> 
> Nevertheless, I have other questions about the IRQ management.
> 
> In fact, after executing my software application (so after the rtdm_close call, and so the free irq), I obtain a syslog message : kernel Disabling IRQ #11. This message doesn't affect my software if I run it again, but may be there are some side effect. In dmesg, the following error message appears : irq 11: nobody cared (try booting with the "irqpoll" option).
> In my open function I call : 
> - request_region
> - rtdm_irq_request
> In my close function I call :
> - rtdm_irq_free
> - release_region
> May be there is a function to call to avoid this disabling irq ?

Are you sure that you properly configured your device to no longer
generate IRQs before unregistering the handler?

> 
> 
> Moreover, when I'm using my discrets I/O driver (on the IRQ 11) and I add an USB Key (on this IRQ 11) the software freeze. Note that my USB Key works normaly before I call my open function, and doesn't work after my software execution, may be because of the Disabling IRQ.
> Note that the freeze appears with the 16550A rtdm driver use. For example, when my keyboard irq is the same as the seria board irq, the computer freeze when the driver is running and the keyboard is using at the same moment.
> I think that the linux irq and xenomai irq are not usable at the same time !
> 
> Note that my kernel is configured with shared interrupt.

Please read the FAQ in the wiki about shared RT/non-RT IRQS.

Jan


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

Re: [Xenomai-help] Interrupt management under rtdm driver

[DOURNES Guillaume]

Problem Resolved 

Thanks a lot.

Guillaume.

-----Message d'origine-----
De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
Envoyé : vendredi 16 mai 2008 09:12
À : DOURNES Guillaume
Cc : xenomai@xenomai.org
Objet : Re: [Xenomai-help] Interrupt management under rtdm driver

DOURNES Guillaume wrote:
> Thanks a lot for your attention. And sorry for my poor english.
> I change my context into a real RT context and my problem disappears.
> 
> Nevertheless, I have other questions about the IRQ management.
> 
> In fact, after executing my software application (so after the rtdm_close call, and so the free irq), I obtain a syslog message : kernel Disabling IRQ #11. This message doesn't affect my software if I run it again, but may be there are some side effect. In dmesg, the following error message appears : irq 11: nobody cared (try booting with the "irqpoll" option).
> In my open function I call : 
> - request_region
> - rtdm_irq_request
> In my close function I call :
> - rtdm_irq_free
> - release_region
> May be there is a function to call to avoid this disabling irq ?

Are you sure that you properly configured your device to no longer generate IRQs before unregistering the handler?

> 
> 
> Moreover, when I'm using my discrets I/O driver (on the IRQ 11) and I add an USB Key (on this IRQ 11) the software freeze. Note that my USB Key works normaly before I call my open function, and doesn't work after my software execution, may be because of the Disabling IRQ.
> Note that the freeze appears with the 16550A rtdm driver use. For example, when my keyboard irq is the same as the seria board irq, the computer freeze when the driver is running and the keyboard is using at the same moment.
> I think that the linux irq and xenomai irq are not usable at the same time !
> 
> Note that my kernel is configured with shared interrupt.

Please read the FAQ in the wiki about shared RT/non-RT IRQS.

Jan

[Xenomai-help] Serial driver and TX events

[Anders Blomdell]

Are there any reason why the serial driver could not be changed to give an event
when all characters has left the TX buffer?


-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Serial driver and TX events

[Jan Kiszka]

Anders Blomdell wrote:
> Are there any reason why the serial driver could not be changed to give an event
> when all characters has left the TX buffer?

No, I don't think so. Somehow I have the feeling someone requested this
feature before, but I cannot find any reference  or even code ATM.
However. Patch would be welcome.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Serial driver and TX events

[Anders Blomdell]

Jan Kiszka wrote:
> Anders Blomdell wrote:
>> Are there any reason why the serial driver could not be changed to give an event
>> when all characters has left the TX buffer?
> 
> No, I don't think so. Somehow I have the feeling someone requested this
> feature before, but I cannot find any reference  or even code ATM.
> However. Patch would be welcome.
OK, I'll see what I can do. Is patch against 2.4.2 OK (pressing deadline -> I do
not have the time to uprade right now).

My need for it is to make it possible to wait until all characters has left the
FIFO (needed for autobaud detection), so perhaps a ioctl RTIOC_DRAIN (similar to
RTIOC_PURGE) is a better choice (you decide what you prefer, and I'll try to
implement it)

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Serial driver and TX events

[Jan Kiszka]

Anders Blomdell wrote:
> Jan Kiszka wrote:
>> Anders Blomdell wrote:
>>> Are there any reason why the serial driver could not be changed to give an event
>>> when all characters has left the TX buffer?
>> No, I don't think so. Somehow I have the feeling someone requested this
>> feature before, but I cannot find any reference  or even code ATM.
>> However. Patch would be welcome.
> OK, I'll see what I can do. Is patch against 2.4.2 OK (pressing deadline -> I do
> not have the time to uprade right now).

Such a patch would currently apply against trunk as-is, at least /wrt
16550A - but I would take care of porting in any case.

> 
> My need for it is to make it possible to wait until all characters has left the
> FIFO (needed for autobaud detection), so perhaps a ioctl RTIOC_DRAIN (similar to
> RTIOC_PURGE) is a better choice (you decide what you prefer, and I'll try to
> implement it)

Hmm, for that particular use case I guess it shouldn't be problematic to
wait the required time after writing some probe character(s).

Otherwise, a blocking RTIOC_DRAIN sounds reasonable. That could become
an (optional) common feature of all buffering RTDM devices.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Serial driver and TX events

[Anders Blomdell]

Jan Kiszka wrote:
> Anders Blomdell wrote:
>> Jan Kiszka wrote:
>>> Anders Blomdell wrote:
>>>> Are there any reason why the serial driver could not be changed to give an event
>>>> when all characters has left the TX buffer?
>>> No, I don't think so. Somehow I have the feeling someone requested this
>>> feature before, but I cannot find any reference  or even code ATM.
>>> However. Patch would be welcome.
>> OK, I'll see what I can do. Is patch against 2.4.2 OK (pressing deadline -> I do
>> not have the time to uprade right now).
> 
> Such a patch would currently apply against trunk as-is, at least /wrt
> 16550A - but I would take care of porting in any case.
> 
>> My need for it is to make it possible to wait until all characters has left the
>> FIFO (needed for autobaud detection), so perhaps a ioctl RTIOC_DRAIN (similar to
>> RTIOC_PURGE) is a better choice (you decide what you prefer, and I'll try to
>> implement it)
> 
> Hmm, for that particular use case I guess it shouldn't be problematic to
> wait the required time after writing some probe character(s).
> 
> Otherwise, a blocking RTIOC_DRAIN sounds reasonable. That could become
> an (optional) common feature of all buffering RTDM devices.

OK, now I know why it is a bad idea. There is no way to get an interrupt when
all characters has left the FIFO and shift register (i.e. no interrupts on TEMT
indicator, and using THRE indicator means that there is still data waiting to
get out). So one could just as easily do it from user space. I.e. like:

  while (1) {
    int err;
    struct rtser_status status;

    err = rt_dev_ioctl(fd, RTSER_RTIOC_GET_STATUS, &status);
    if (err < 0) { break; }
    if (status.line_status & RTSER_LSR_TRANSM_EMPTY) { break; }
    rt_task_sleep(1000000);
  }

Sorry about the noise...

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

[Xenomai-help] Weird rt_dev_socket behaviour

[Anders Blomdell]

With xenomai-2.4.2 and rtnet-0.9.10, is it expected that the following code:

  ...
  mlockall(MCL_CURRENT|MCL_FUTURE);
  rt_task_shadow(&task_self, NULL, 1, T_FPU);
  fd = rt_dev_socket(AF_PACKET, SOCK_DGRAM, 0);
  if (fd < 0) {
    fprintf(stderr, "failed to create socket %d\n", fd);
    exit(1);
  }
  ...

fails with the message "failed to create socket -12", while the following works
as expected:

  ...
  mlockall(MCL_CURRENT|MCL_FUTURE);
  rt_task_shadow(&task_self, NULL, 1, T_FPU);
  rt_task_set_mode(T_PRIMARY, 0, 0);
  fd = rt_dev_socket(AF_PACKET, SOCK_DGRAM, 0);
  if (fd < 0) {
    fprintf(stderr, "failed to create socket %d\n", fd);
    exit(1);
  }
  ...

Regards

Anders Blomdell


-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

Re: [Xenomai-help] Weird rt_dev_socket behaviour

[Jan Kiszka]

Anders Blomdell wrote:
> With xenomai-2.4.2 and rtnet-0.9.10, is it expected that the following code:
> 
>   ...
>   mlockall(MCL_CURRENT|MCL_FUTURE);
>   rt_task_shadow(&task_self, NULL, 1, T_FPU);
>   fd = rt_dev_socket(AF_PACKET, SOCK_DGRAM, 0);
>   if (fd < 0) {
>     fprintf(stderr, "failed to create socket %d\n", fd);
>     exit(1);
>   }
>   ...
> 
> fails with the message "failed to create socket -12", while the following works
> as expected:
> 
>   ...
>   mlockall(MCL_CURRENT|MCL_FUTURE);
>   rt_task_shadow(&task_self, NULL, 1, T_FPU);
>   rt_task_set_mode(T_PRIMARY, 0, 0);
>   fd = rt_dev_socket(AF_PACKET, SOCK_DGRAM, 0);
>   if (fd < 0) {
>     fprintf(stderr, "failed to create socket %d\n", fd);
>     exit(1);
>   }
>   ...

Yes, this is an RTnet artifact. Check rtnet/Documentation/README.pools
on details how to prepare rt-socket creation from primary domains - but
generally you don't want this, and RTnet will sooner or later remove the
related support (and source of confusion).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux