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

From: Jiang Liu
Date: Fri Jun 19 2015 - 12:48:22 EST

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)

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?
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

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

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