On Fri, 2009-08-14 at 21:52 +0200, Waschk,Kolja wrote: > >>> 0 277 10210 20412 0 00320186 2.5 Head_UDP_Thread > > UDP, like... socket() interface? > > No. There's a custom RTDM driver with a DMA completion ISR and an IOCTL_RT > that > can be used by the application to fetch a pointer to received data. The > thread > has "UDP" in its name because the data comes in UDP-like packets over a > Blackfin SPORT interface, and on other platforms (PC) the code indeed uses > Ethernet and real sockets for reception. >
Ok. > Hmm, the solution to my question may be very simple. In the past I had to > enclose the ioctl call to the driver with explicit mode switches, because > otherwise the application would always crash (remember my previous problem > with > the xnshadow_relax() symptom). They're still there. I somehow expected the > SIGXCPU to occur even before the first ioctl is made. But if that doesn't > happen, and an explicit call to rt_task_set_mode doesn't cause SIGXCPU, Indeed, it does not, since clearing the T_PRIMARY bit this way is an action which is supposed to be done willingly by the application code, so there is normally no point in notifying it about the mode switch it just asked for. > that > may be the (silly) cause... Unfortunately I can't check right now. Will report > if that's it... > > Kolja > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
