[LITMUS^RT] BUG: Dropped Tasks

Björn Brandenburg bbb at mpi-sws.org
Thu Jan 23 00:00:01 CET 2014


On 22 Jan 2014, at 20:49, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> 
> I’ve run into a bug in Litmus, and I just wanted to pass it on.  I don’t have a fix for it yet.  Since we don’t have a formal bug tracking mechanism in place, I thought that I would just report it here.

The Github project has a bug tracker included, we could simply use that.

	https://github.com/LITMUS-RT/litmus-rt/issues

> 
> Bug: Task is unlinked, but it is not put back on a ready queue.  As a result, the task is never rescheduled.  (This is under C-EDF, as well as Jeremy’s related C-FL scheduler.)
> 
> I first observed it over the winter break while gathering overhead measurements using Jonathan’s experiment-scripts.  The bug would happen while running a large task set of rtspin-based tasks.  The bug is rare.  It occurs maybe once every two hours on my test system (UNC’s ludwig).  I spent last weekend trying to reproduce the bug with TRACE() enabled.  Unfortunately, tracing seems to make the bug much less likely to occur.  I was only able to reproduce it once over many hours of task set execution.  Sadly, the TRACE buffer experienced an overflow when the bug tripped, so I couldn’t investigate further.  (This does imply that the bug may be related to heavy utilization since the ring buffer was prevented from emptying.)
> 
> This bug may or may not be related to the non-preemption bug that I reported last week.  I can’t say if using non-preemption made triggering the above bug more likely, or if last week’s bug is unrelated.

Thanks for the report. Do you know whether this typically happens shorty after or before a plugin switch? We ran into some issues related to the stop_sched_class coming before the LITMUS^RT scheduling class, which caused bugs in rare cases. I recently pushed a workaround to staging for this, maybe you can try reproducing with this patch applied?

	https://github.com/LITMUS-RT/litmus-rt/commit/7021d6c73b3e4ae4b154950d781b96d40f5218bb

Thanks,
Björn





More information about the litmus-dev mailing list