On 23/12/21 11:58, John Keeping wrote: > On Wed, Dec 22, 2021 at 07:48:33PM +0000, Valentin Schneider wrote: >> mark_wakeup_next_waiter() first deboosts the previous owner and then >> wakeups the next top waiter. Seems like you somehow have the wakeup happen >> before the push_rt_task IRQ work is run. Also, tell_cpu_to_push() should >> only pick a CPU that is in rq->rd->rto_mask, which requires having at least >> 2 RT tasks there... >> >> Now, that wakeup from the rtmutex unlock would give us a resched_curr() via >> check_preempt_curr() if required, which is good, though I think we are >> still missing some for sched_setscheduler() (there are no wakeups >> there). So if we just have to live with an IRQ work popping in before we >> get to preempt_schedule_irq() (or somesuch), then perhaps the below would >> be sufficient. > > With this patch I ran 100 reboots without hitting the BUG, so it looks > like this is the solution! > > If you post this as a patch, feel free to add: > > Tested-by: John Keeping <john@xxxxxxxxxxxx> Thanks! I still need to convince myself beyond reasonable doubt that this is really what is happening (esp the sched_setscheduler()) part, so the next episode will probably air after the break :-)
