Steven Seeger wrote: > This is probably an application error, but I am having some random weird > behavior where sometimes a double that I add 0.01 to in a periodic task > gets corrupted and becomes nan. I didn't specify the T_FPU flag in > rt_task_spawn() but the docs said that flag is assumed for a user space > task. I've since set that flag manually and haven't had the problem > happen yet. Is this just a coincidence? >
Likely, as T_FPU is hard-coded for user space threads. You could try to strip down your test so that incorrect application behaviour can be excluded (or use the test below). > > > The corruption seems to happen in a half-second window where the system > is doing a lot and only about 35% of the CPU is available to Linux. > However, I am testing for overruns on rt_task_wait_period() and never > seeing any. Overload must not cause data corruption, "only" missed deadlines. This case needs closer examination. As some first step: there is the switchtest tool coming with Xenomai. It includes consistency checks of the FPU environment across context switches. Maybe you can give this a try under similar load conditions over a longer period. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
