<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Well, I am stuck in a strange case where a task is linked but never scheduled (G-EDF):<div><br></div><div><div><b>3903 P0 [check_for_preemptions@litmus/sched_gsn_edf.c:365]: check_for_preemptions: attempting to link task 1795 to 0</b></div><div>3904 P0 [gsnedf_get_nearest_available_cpu@litmus/sched_gsn_edf.c:347]: Could not find an available CPU close to P0 </div><div>3905 P0 [__add_ready@litmus/rt_domain.c:312]: rt: adding aux_threads/1799 (0, 4611686018427387903, 4611686018427387903) [inh_task: (nil)/0 (0, 0 0)] rel=59812157846 to ready queue at 60312058176</div><div>3907 P0 [link_task_to_cpu@litmus/sched_gsn_edf.c:218]: (aux_threads/1799:1) <b>linked = aux_threads/1795</b></div><div>3908 P0 [link_task_to_cpu@litmus/sched_gsn_edf.c:219]: (aux_threads/1799:1) entry->linked = aux_threads/1799</div><div><b>3909 P0 [link_task_to_cpu@litmus/sched_gsn_edf.c:261]: (aux_threads/1795:2) linked to 0. </b></div><div>3914 P1 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1796:1) tick</div><div>3915 P2 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1797:1) tick</div><div>3916 P3 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1798:1) tick</div><div><b>3917 P0 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1799:1) tick</b></div><div>3918 P1 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1796:1) tick</div><div>3919 P2 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1797:1) tick</div><div>3920 P3 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1798:1) tick</div><div><b>3921 P0 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1799:1) tick</b></div><div>3922 P1 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1796:1) tick</div><div>3923 P2 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1797:1) tick</div><div>3924 P3 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1798:1) tick</div><div><b>3925 P0 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1799:1) tick</b></div><div>3926 P1 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1796:1) tick</div><div>3927 P2 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1797:1) tick</div><div>3928 P3 [gsnedf_tick@litmus/sched_gsn_edf.c:472]: (aux_threads/1798:1) tick</div></div><div><br></div><div><br></div><div>I updated gsnedf_tick to print the currently scheduled real-time task. Task 1795 should be running on P0 instead of 1799.</div><div><br></div><div>Has anyone ever seen something like this before?</div><div><br></div><div>Thanks,</div><div>Glenn</div><div><br></div><div>p.s. Ignore the crazy period/relative_deadline for 1799. Those are just place holders. 1799 is really just a worker thread that has a statically low priority and should only run when the system is idle (or according to an inherited priority).</div><div><br></div><div>p.p.s. I think there is a bug in litmus.c::litmus_fork(). is_realtime() is returning false for forked children of a real-time task (expected), so the fork-copied rt_param state is not reset. Thus, the child gets the same rt_params as the parent. This is probably harmless if we're sure to re-init any children that transition to real-time. However, for the sake of completeness, I wonder if we should execute "reinit_litmus_state(p,0);" for all children. I am doing some where tasks are forced to become real-time from within the kernel (worker threads), and this possible bug bit me.</div></body></html>