Re: panic kexec broken on ARM64?

From: James Morse <james.morse@arm.com>
To: "takahiro.akashi@linaro.org" <takahiro.akashi@linaro.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Matthias Brugger <mbrugger@suse.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	kexec mailing list <kexec@lists.infradead.org>,
	Petr Tesarik <ptesarik@suse.cz>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: panic kexec broken on ARM64?
Date: Wed, 4 Jul 2018 13:47:11 +0100	[thread overview]
Message-ID: <3df2d32d-867b-2237-d2a0-9fd6d7302eb3@arm.com> (raw)
In-Reply-To: <20180704084123.GC28220@linaro.org>

Hi Akashi,

On 04/07/18 09:41, takahiro.akashi@linaro.org wrote:
> On Tue, Jul 03, 2018 at 09:58:44AM +0100, Marc Zyngier wrote:
>> On 03/07/18 08:01, takahiro.akashi@linaro.org wrote:
>>> On Sun, Jun 10, 2018 at 01:24:17PM +0100, Marc Zyngier wrote:
>>>> On Wed, 06 Jun 2018 12:37:02 +0100 James Morse wrote:,
>>>>> Bingo: its the lan78xx driver that is sleeping from the irqchip
>>>>> callbacks; The smsc95xx driver doesn't have a struct irq_chip, which
>>>>> is why the RPi-3-B doesn't do this.
>>>>>
>>>>> It may be valid for kdump to only teardown the 'root irqdomain' (if
>>>>> that even means anything). I assume these secondary irqchip's would
>>>>> have a summary-interrupt that goes to another irqchip. But I can't
>>>>> see a way to tell them apart..,

>>>> Overall, I can't think of an easy fix. We have a few options, but none
>>>> of them involve a centralised change:
>>>>
>>>> 1) We provide a reset infrastructure for irqchips, with an opt-in
>>>>    mechanism. This involves changing the way we teardown irqs at
>>>>    crash-time, and we'd then need some notion of reset ordering (think
>>>>    of the layered ITS and GICv3, for example).
>>>
>>> Does this mean that all the irqchips have to be implemented with reset?
>>
>> No. Only those that want to be reset at kexec time.
> 
> I don't get the point yet.

(this stuff is new to me, below terminology is probably wrong:)

It seems there is actually a tree of irqchips, which feed interrupts through the
tree via some summary-interrupt.
The problem is one of these later-irqchips is on the other end of the USB bus,
and requires a fair amount of sleeping in order to reset it.

The trick is everything comes through the root irqchip. So we can reset that to
disable all the other interrupts in this tree.

This only works until the new kernel re-enables the summary-interrupt, it needs
to reset the irqchip that the summary-interrupt leads to first.

(I assume shared summary-interrupts are somehow forbidden).

> Who should have reset interface?
> What is the criteria?

(reset-interface -> be reset at kdump time)

Just the root irchip that all interrupts have to come through.

Thanks,

James

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec