All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] RTDM Questions
@ 2005-12-23 15:16 Sean McGranaghan
  2005-12-27  1:00 ` Jan Kiszka
  0 siblings, 1 reply; 2+ messages in thread
From: Sean McGranaghan @ 2005-12-23 15:16 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/html, Size: 2219 bytes --]

[-- Attachment #2: test.tar.gz --]
[-- Type: application/x-gzip, Size: 152838 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Xenomai-help] RTDM Questions
  2005-12-23 15:16 [Xenomai-help] RTDM Questions Sean McGranaghan
@ 2005-12-27  1:00 ` Jan Kiszka
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Kiszka @ 2005-12-27  1:00 UTC (permalink / raw)
  To: Sean McGranaghan; +Cc: xenomai-help


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

Sean McGranaghan wrote:
> Hello all,
> 
> First all let me say thanks for all the help to this point. This group has 
> always responded quickly to my questions. You are all doinga great job getting 
> the Xenomai system out there and building a comminity around it.
> 
> I have been writing an RTDM driver and came across two issues. I am using 
> Xenomai 2.0 with a 2.6.14.3 Kernel. I have attached a driver and test 
> application to demonstrate the issues. The test driver creates an RT_QUEUE with 
> a simple ioctl() send/recv interface. (This driver is for demonstration only, it 
> does nothing useful) The test application is used to run simple 
> open/close/send/recv operations on the device. The driver is created for 
> exclusive access.
> 
> The driver and test application can be built with the given make files. Once 
> built you can run the test application with no arguments to get the program usage.
> 
> Issue 1: It appears there is a null reference bug in the RTDM code. Load the 
> driver module and then run test 2 of the test application. When the second 
> device open is executed you get a kernel oops instead of a device busy error 
> status. (Please ignore this question if this is fixed in the latest version of 
> 2.0.x. I am in the process of building a new test box with the latest version.)

Kind of zombie bug: I could have sworn having this one fixed in some
earlier RTDM revision, maybe even one of the RTnet-only days. Anyway,
the attached patch (rtdm-excl-dev.patch) fixes it - finally. Thanks for
reporting.

@Philippe: please apply to both trees.

> 
> Issue 2: I am trying to figure out how signals are received and processed in 
> realtime tasks. Here is the scenario. Run test 4. The test application creates a 
> realtime task that waits indefinitely on the RT_QUEUE. The application will wait 
> for a signal from the user (SIGINT). When the signal is sent I can see the 
> kernel log indicate that the driver was interrupted on the queue receive. I 
> would expect the realtime task to get an EINTR back from the ioctl(), but the 
> task never gets control back after the signal. What am I missing here?
> 

Well, this is actually no Xenomai or RTDM issue here. If you don't catch
SIGINT, your process will terminate on arrival. Thus there is no chance
for the test task to grab the driver's EINTR. If you catch it via
signal(), the main thread always seems to get it, not the (real-time)
sub-threads. That's what makes signals so "nice" in multithreaded
environments... Try to play with pthread_sigmask or pthread_kill to
create the test scenario you want.

While reading and testing your code I discovered one pitfall: you did
not register some non-RT close handler. In case the application failed
to close the device, I was not able to enforce a closure via "echo
FILE_DESCR > /proc/xenomai/rtdm/open_fildes". That made your driver
un-removable in this case.

To avoid such issues in the future, especially when we once may add
auto-cleanup during process termination, I decided to enforce the
registeration of a non-RT handler for close (rtdm-nrt-close.patch).

@Philippe: please apply this one to SVN trunk.

Jan

[-- Attachment #1.2: rtdm-excl-dev.patch --]
[-- Type: text/x-patch, Size: 682 bytes --]

Index: ksrc/skins/rtdm/core.c
===================================================================
--- ksrc/skins/rtdm/core.c	(Revision 304)
+++ ksrc/skins/rtdm/core.c	(Arbeitskopie)
@@ -129,7 +129,7 @@
 
     xnlock_put_irqrestore(&rt_fildes_lock, s);
 
-    *context_ptr = context = device->reserved.exclusive_context;
+    context = device->reserved.exclusive_context;
     if (context) {
         xnlock_get_irqsave(&rt_dev_lock, s);
 
@@ -140,6 +140,8 @@
         context->device = device;
 
         xnlock_put_irqrestore(&rt_dev_lock, s);
+
+        *context_ptr = context;
     } else {
         if (nrt_mem)
             context = kmalloc(sizeof(struct rtdm_dev_context) +


[-- Attachment #1.3: rtdm-nrt-close.patch --]
[-- Type: text/x-patch, Size: 597 bytes --]

Index: ksrc/skins/rtdm/device.c
===================================================================
--- ksrc/skins/rtdm/device.c	(Revision 304)
+++ ksrc/skins/rtdm/device.c	(Arbeitskopie)
@@ -233,9 +233,10 @@
             return -EINVAL;
     }
 
-    /* Sanity check: any close handler? */
-    if (NO_HANDLER(device->ops, close)) {
-        xnlogerr("RTDM: no close handler\n");
+    /* Sanity check: non-RT close handler?
+     * (Always required for forced cleanup) */
+    if (!device->ops.close_nrt) {
+        xnlogerr("RTDM: no non-RT close handler\n");
         return -EINVAL;
     }
 


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-12-27  1:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-23 15:16 [Xenomai-help] RTDM Questions Sean McGranaghan
2005-12-27  1:00 ` Jan Kiszka

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.