linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: A problem about interrupt when booting a captured kernel
Date: Wed, 18 Nov 2015 11:29:29 +0000	[thread overview]
Message-ID: <564C6119.2050704@arm.com> (raw)
In-Reply-To: <564C30D9.7030108@linaro.org>

On 18/11/15 08:03, AKASHI Takahiro wrote:
> On 11/17/2015 06:07 PM, Marc Zyngier wrote:
>> On Tue, 17 Nov 2015 10:05:23 +0900
>> AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
>>
>>> Marc,
>>> (Cc: Mark)
>>>
>>> On 11/17/2015 04:26 AM, Marc Zyngier wrote:
>>>> On 13/11/15 10:09, Yang Yingliang wrote:
>>>>> Hi, Marc
>>>>>
>>>>>
>>>>>        The kexec will boot a captured kernel while the kernel panic. But
>>>>> it boots failed if the kernel panic in handler function of PPI. The
>>>>> reason is that the PPI has not been 'eoi', other interrupts can not be
>>>>> handled when booting  the captured kernel.
>>>>>
>>>>>        The kexec will call irq_eoi to end the irqs that have
>>>>> IRQD_IRQ_INPROGRESS flag. But PPIs don't have this flag, so it won't be
>>>>> ended.
>>>>>
>>>>>       Three ways to solve this problem we can think :
>>>>>       1. Is there a way to reset gic like its_reset ?
>>>>>       2. Can we add some flag for calling irq_eoi ?
>>>>>       3. Just 'eoi' all PPIs without checking flags in kexec.
>>>>>
>>>>>        Please give some advice.
>>>>
>>>> Good timing. Please see:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/385383.html
>>>
>>> I removed machine_kexec_mask_interrupts() from my arm64 kdump patch series[1]
>>> due to the past discussions[2].
>>>
>>> Is it the time that I should resurrect the code?
>>
>> Probably.
> 
> Let me make sure.
> Have your patches here, especially #1, also addressed the issue that you pointed out
> in [1]?
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338969.html

Patch #1 still has the current behaviour (deactivate any in flight
interrupt), but does it in a more complete way. The additional 3 patches
make sure that the GIC (any version) is not affected by having active
interrupts when getting initialized.

These are the two sides of the same coin, basically. I'm still not fond
of what we do in machine_kexec_mask_interrupts(), but we can't rely on
the secondary kernel doing the right thing either.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-11-18 11:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 10:09 A problem about interrupt when booting a captured kernel Yang Yingliang
2015-11-16 19:26 ` Marc Zyngier
2015-11-17  1:05   ` AKASHI Takahiro
2015-11-17  9:07     ` Marc Zyngier
2015-11-18  8:03       ` AKASHI Takahiro
2015-11-18 11:29         ` Marc Zyngier [this message]
2015-11-17  3:48   ` Yang Yingliang
2015-11-17  9:16     ` Marc Zyngier
2015-11-19  3:42       ` Yang Yingliang
2015-11-19  8:40         ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=564C6119.2050704@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).