On 15/04/2021 13:41, jun.miao wrote:
On 4/15/21 7:12 PM, Tvrtko Ursulin wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi,
On 14/04/2021 15:48, Jun Miao wrote:
Don`t simple disable all the HD-irq, should race the region in the
intel_breadcrumbs_disarm_irq() only.
What is HD-irq, I am, not familiar with that term?
Disable local interrupt delivery from Hardware of cpu.:-)
HW then, not HD. ;)
[...]
static void add_signaling_context(struct intel_breadcrumbs *b,
@@ -337,9 +339,7 @@ void __intel_breadcrumbs_park(struct
intel_breadcrumbs *b)
/* Kick the work once more to drain the signalers, and disarm
the irq */
irq_work_sync(&b->irq_work);
while (READ_ONCE(b->irq_armed) && !atomic_read(&b->active)) {
- local_irq_disable();
signal_irq_work(&b->irq_work);
- local_irq_enable();
Unfortunately there is another lock inside signal_irq_work (rq->lock)
which needs to be taken irq safe.
Ok, i will change the left spin_lock -> spin_lock_irqsave.
In fact, inside signal_irq_work, intel_breadcrumbs_arm_irq
(&b->irq_lock) which also needs to be taken irq safe.
Thanks,
Jun
RT patches are in tree or out of the tree these days?
I base on the mainline kernel tree， and this BUG warning will not
happen. But RT v5.10 will complain "BUG warning", so i want this patch
will solve RT WARNING without affecting mainline performance in mainline
tree.
So the problem is we did not typically do changes to cater for out of
tree stuff, unless they are really minimal. And this one in my view does
not quite qualify as such.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
