Re: [-next] !irqd_can_balance() WARNINGs at irq_move_masked_irq()

[Jiang Liu]

On 2015/6/20 0:30, Thomas Gleixner wrote:
> On Sat, 20 Jun 2015, Jiang Liu wrote:
>> On 2015/6/20 0:15, Thomas Gleixner wrote:
>>> On Sat, 20 Jun 2015, Jiang Liu wrote:
>>>
>>>> [...]
>>>>>> Something in the kernel (not yet clear what) tries to move the hpet
>>>>>> irq 0 by calling irq_set_affinity(). That's an kernel internal
>>>>>> interface which does not check whether the NO BALANCE flag is set for
>>>>>> the irq. So the call runs and triggers the move from next interrupt
>>>>>> machinery which ends up calling irq_move_masked_irq() and that trips
>>>>>> over the flag and yells.
>>>>>>
>>>>>> That's why I changed the WARN to a pr_warn() because we already know
>>>>>> the call stack.
>>>>>>
>>>>>> So the core behaviour is inconsistent. We let the caller of
>>>>>> irq_set_affinity() succeed and yell later because we think it's wrong.
>>>>>>
>>>>>> I'm pretty sure that we must drop the check for NO BALANCE in
>>>>>> irq_move_masked_irq() and only check for the per_cpu bit, but at the
>>>>>> same time I really want to know where that call to irq_set_affinity(irq0)
>>>>>> is coming from.
>>>>>>
>>>>>> Can you please collect the output of /proc/timer_list for the previous
>>>>>> patch and then replace the previous patch with the one below and
>>>>>> gather all the data again?
>>>>>
>>>>> Hi Thomas,
>>>>> 	Maybe it's caused by the hpet driver itself?
>>>>> irq_set_affinity() may set the IRQD_SETAFFINITY_PENDING flag,
>>>>> thus triggering the warning.
>>>> And the usage pattern seems reasonable, the IRQF_NOBALANCING flag
>>>> means nobody may change the affinity except myself:)
>>>
>>> Right, that's why I removed the restriction. I just wonder why we have
>>> not seen that before ...
>> I suspected it's caused by the hierarchy irqdomain at first glance
>> because the multiple irq_datas issue, but seems it's not after checking
>> the code. It will only be triggered if HPET works in MSI mode instead of
>> legacy IRQ mode, but still need more investigation here.
> 
> Right. And what confuses me is that this happens on irq0, which is
> ioapic edge.
Hi Thomas,
	One possible cause is that hpet_assign_irq() fails, and the
code below treats 0 as a valid irq number(which should be fixed).
----------------------------------------------------------------------
static void hpet_msi_capability_lookup()
{
	.........................
                irq = hpet_assign_irq(hpet_domain, hdev, hdev->num);
                if (irq < 0)
                        continue;

                sprintf(hdev->name, "hpet%d", i);
                hdev->num = i;
                hdev->irq = irq;
                hdev->flags = 0;
	...............................
}

Hi Sergey,
	Could you please help to apply the debug patch below
and check the log message?
Thanks!
Gerry
--------------------------------------------------------------------
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 40cf79a55fe7..28a65d94fd89 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -578,8 +578,11 @@ static void hpet_msi_capability_lookup(unsigned int
start_timer)
                        continue;

                irq = hpet_assign_irq(hpet_domain, hdev, hdev->num);
-               if (irq < 0)
+               if (irq <= 0) {
+                       pr_warn("irqdomain: fails to allocate irq for
hpet%d\n",
+                               hdev->num);
                        continue;
+               }

                sprintf(hdev->name, "hpet%d", i);
                hdev->num = i;
-----------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/