lkml.org 
[lkml]   [2015]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [-next] !irqd_can_balance() WARNINGs at irq_move_masked_irq()
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/
\
 
 \ /
  Last update: 2015-06-19 19:01    [W:1.452 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site