On 08/03/18 22:06, Grzegorz Jaszczyk wrote:
> 2018-03-02 17:57 GMT+01:00 Mark Rutland <mark.rutl...@arm.com>:
>>>>> Do you see this for a panic() in *any* interrupt handler?
>>>> I only test with this two interrupt handlers: watchdog and i2c but I
>>>> think it will behave the same with others - I can try with other if
>>>> you want, any suggestion which? Maybe with some PPI interrupt instead?
> I was able to reproduce it from other interrupts handler (UART, I2C,
> timer and watchdog) no difference if it is PPI or SPI interrupt. I
> also reproduce this issue with GICv3. But again it only happens when
> eoimode = 0.
>>>>> Can you trigger the issue with magic-sysrq c, for example?
>>>> There is no problem when I trigger it via 'echo c >
>>>> /proc/sysrq-trigger' - it works well all the time. The problem appears
>>>> only, when the kexec/kdump procedure is triggered from interrupt
>>> I'd meant that you'd send sysrq + c over serial, rather than writing to
>>> /proc/sysrq-trigger. That way, the panic will be in the context of the
>>> UART IRQ handler.
>>> If that shows the issue, that's ilikely to be the easiest way for
>>> someone else to reproduce and investigate this.
> Yes it can be triggered by sending sysrq + c and indeed it is the
> easiest way to reproduce it.
>> FWIW, having just given this a go on my Juno R1 with v4.16-rc3
>> defconfig, the UART IRQs work fine in the crash kernel. That crash
>> happened in IRQ context:
> I think that by default Juno uses eoimode = 1, did you try it when
> eoimode was forced to be 0? Only eoimode = 0 triggers the issue.
FWIW, I've now posted fixes to LKML. Feel free to test them and
report whether they fix the issue for you.
Jazz is not dead. It just smells funny...