M. Koehrer wrote: > Hi everybody, > > I have one strange issue with rtnet (latest SVN version and RTAI 3.3 on a SMP > Pentium 4, kernel 2.6.16): > In my application I do regularly UDP reads using rt_dev_recv with a fairly > long timeout (12 seconds). > The timeout is set before using rt_dev_ioctl(...RTNET_IOCTL_TIMEOUT). > This works fine. > However, while shuting down my application and rtnet while I am still waiting > for the timeout > I get the error message from RTDM: RTDM: device still in use - waiting for > release... > Up to this point I have performed the following steps: > rmmod my kernel module > rtifconfig down > rmmod rt_eepro100 > It is not possible any more to rmmod rtipv4 and I have to restart my PC to > continue.
Check /proc/rtai/rtdm/open_fildes. There should be at least one stalled file descriptor be displayed. You can clean it up with "echo <fd> > /proc/rtai/rtdm/open_fildes". > If I wait longer than my timeout time, I can shut down everything without any > problem. > > More details: > I use a kernel module for UDP communication. > In the cleanup_module I do a rt_task_suspend() followed by a rt_task_delete(). > Then rt_dev_close(sock) is called. The creation of the socket is done in > init_module, not in the task! That's a more or less broken cleanup scheme (killing tasks at arbitrary execution points is always fragile). Take a look at existing examples: first close the socket some RT-task is blocking on. This will wake it up and let the call return with an error. You can then safely self-terminate your task while the triggering non-RT task joins on it (or polls for its termination). Doing it the other way around causes this kind of deadlock. Hope we will solve this in the future by per-process RT-resource cleanup. RTDM and RTnet are at least prepared for this. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
