* A problem about interrupt when booting a captured kernel @ 2015-11-13 10:09 Yang Yingliang 2015-11-16 19:26 ` Marc Zyngier 0 siblings, 1 reply; 10+ messages in thread From: Yang Yingliang @ 2015-11-13 10:09 UTC (permalink / raw) To: linux-arm-kernel 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. Thanks Yang ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 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 3:48 ` Yang Yingliang 0 siblings, 2 replies; 10+ messages in thread From: Marc Zyngier @ 2015-11-16 19:26 UTC (permalink / raw) To: linux-arm-kernel 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 and let me know if that fixes things for you. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-16 19:26 ` Marc Zyngier @ 2015-11-17 1:05 ` AKASHI Takahiro 2015-11-17 9:07 ` Marc Zyngier 2015-11-17 3:48 ` Yang Yingliang 1 sibling, 1 reply; 10+ messages in thread From: AKASHI Takahiro @ 2015-11-17 1:05 UTC (permalink / raw) To: linux-arm-kernel 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? [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/383581.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/362414.html Thanks, -Takahiro AKASHI > and let me know if that fixes things for you. > > Thanks, > > M. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-17 1:05 ` AKASHI Takahiro @ 2015-11-17 9:07 ` Marc Zyngier 2015-11-18 8:03 ` AKASHI Takahiro 0 siblings, 1 reply; 10+ messages in thread From: Marc Zyngier @ 2015-11-17 9:07 UTC (permalink / raw) To: linux-arm-kernel 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. Thanks, M. -- Jazz is not dead. It just smells funny. ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-17 9:07 ` Marc Zyngier @ 2015-11-18 8:03 ` AKASHI Takahiro 2015-11-18 11:29 ` Marc Zyngier 0 siblings, 1 reply; 10+ messages in thread From: AKASHI Takahiro @ 2015-11-18 8:03 UTC (permalink / raw) To: linux-arm-kernel 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 -Takahiro AKASHI > Thanks, > > M. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-18 8:03 ` AKASHI Takahiro @ 2015-11-18 11:29 ` Marc Zyngier 0 siblings, 0 replies; 10+ messages in thread From: Marc Zyngier @ 2015-11-18 11:29 UTC (permalink / raw) To: linux-arm-kernel 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... ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-16 19:26 ` Marc Zyngier 2015-11-17 1:05 ` AKASHI Takahiro @ 2015-11-17 3:48 ` Yang Yingliang 2015-11-17 9:16 ` Marc Zyngier 1 sibling, 1 reply; 10+ messages in thread From: Yang Yingliang @ 2015-11-17 3:48 UTC (permalink / raw) To: linux-arm-kernel Hi On 2015/11/17 3:26, 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 > > and let me know if that fixes things for you. I tried patch #1, deactivating interrupt can not fix the problem. But EOI the interrupt can. I think the reason is GICC status is not cleared. So if it means, in hardware, we should clear the GICC status while deactivating the. Thanks Yang > > Thanks, > > M. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-17 3:48 ` Yang Yingliang @ 2015-11-17 9:16 ` Marc Zyngier 2015-11-19 3:42 ` Yang Yingliang 0 siblings, 1 reply; 10+ messages in thread From: Marc Zyngier @ 2015-11-17 9:16 UTC (permalink / raw) To: linux-arm-kernel On Tue, 17 Nov 2015 11:48:07 +0800 Yang Yingliang <yangyingliang@huawei.com> wrote: > Hi > > On 2015/11/17 3:26, 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 > > > > and let me know if that fixes things for you. > > I tried patch #1, deactivating interrupt can not fix the problem. But > EOI the interrupt can. You have noticed that this patch is for ARM, not arm64, right? > I think the reason is GICC status is not cleared. > So if it means, in hardware, we should clear the GICC status while > deactivating the. Writing to the EOI register or writing to the ACTIVE register have the exact same result as far as kexec is concerned (unless your GIC is not compliant with the architecture - in which case I can't help you). Does applying the other patches help? Thanks, M. -- Jazz is not dead. It just smells funny. ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-17 9:16 ` Marc Zyngier @ 2015-11-19 3:42 ` Yang Yingliang 2015-11-19 8:40 ` Marc Zyngier 0 siblings, 1 reply; 10+ messages in thread From: Yang Yingliang @ 2015-11-19 3:42 UTC (permalink / raw) To: linux-arm-kernel On 2015/11/17 17:16, Marc Zyngier wrote: > On Tue, 17 Nov 2015 11:48:07 +0800 > Yang Yingliang <yangyingliang@huawei.com> wrote: > >> Hi >> >> On 2015/11/17 3:26, 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 >>> >>> and let me know if that fixes things for you. >> >> I tried patch #1, deactivating interrupt can not fix the problem. But >> EOI the interrupt can. > > You have noticed that this patch is for ARM, not arm64, right? Yes, I noticed. > >> I think the reason is GICC status is not cleared. >> So if it means, in hardware, we should clear the GICC status while >> deactivating the. > > Writing to the EOI register or writing to the ACTIVE register have the > exact same result as far as kexec is concerned (unless your GIC is not > compliant with the architecture - in which case I can't help you). > > Does applying the other patches help? No, it doesn't help. > > Thanks, > > M. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* A problem about interrupt when booting a captured kernel 2015-11-19 3:42 ` Yang Yingliang @ 2015-11-19 8:40 ` Marc Zyngier 0 siblings, 0 replies; 10+ messages in thread From: Marc Zyngier @ 2015-11-19 8:40 UTC (permalink / raw) To: linux-arm-kernel On 19/11/15 03:42, Yang Yingliang wrote: > > > On 2015/11/17 17:16, Marc Zyngier wrote: >> On Tue, 17 Nov 2015 11:48:07 +0800 >> Yang Yingliang <yangyingliang@huawei.com> wrote: >> >>> Hi >>> >>> On 2015/11/17 3:26, 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 >>>> >>>> and let me know if that fixes things for you. >>> >>> I tried patch #1, deactivating interrupt can not fix the problem. But >>> EOI the interrupt can. >> >> You have noticed that this patch is for ARM, not arm64, right? > > Yes, I noticed. > >> >>> I think the reason is GICC status is not cleared. >>> So if it means, in hardware, we should clear the GICC status while >>> deactivating the. >> >> Writing to the EOI register or writing to the ACTIVE register have the >> exact same result as far as kexec is concerned (unless your GIC is not >> compliant with the architecture - in which case I can't help you). >> >> Does applying the other patches help? > > No, it doesn't help. That's pretty annoying. It means that on your implementation, clearing the ACTIVE bit doesn't deactivate an interrupt. Great! This probably also break KVM's guest timer in 4.3. Using EOI won't help either because you don't know whether to do a priority drop (which has to happen in reverse order w.r.t. the read of IAR) or a deactivate (and no matter how many flag you add, you still won't know). Can you please get in touch with your HW folks so that they can explain: 1) why it doesn't work, 2) if there is any workaround. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-11-19 8:40 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.