Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
References: <20200729033934.22349-1-alison.wang@nxp.com> <877dumbtoi.fsf@kurt> <20200729094943.lsmhsqlnl7rlnl6f@skbuf> <87mu3ho48v.fsf@kurt> <20200730082228.r24zgdeiofvwxijm@skbuf> <873654m9zi.fsf@kurt> <20200803081625.czdfwcpw5emcd4ls@skbuf> <f61560f5-c4e0-a40b-5845-af3f6d98c7ad@arm.com> <20200803113841.pqqpo4hqfwru3upq@skbuf>
User-agent: mu4e 0.9.17; emacs 26.3
From:   Valentin Schneider <valentin.schneider@arm.com>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Robin Murphy <robin.murphy@arm.com>,
        Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>,
        paulmck@kernel.org, Anna-Maria Gleixner <anna-maria@linutronix.de>,
        catalin.marinas@arm.com, Alison Wang <alison.wang@nxp.com>,
        linux-kernel@vger.kernel.org, leoyang.li@nxp.com,
        vladimir.oltean@nxp.com, Thomas Gleixner <tglx@linutronix.de>,
        mw@semihalf.com, will@kernel.org,
        linux-arm-kernel@lists.infradead.org, Marc Zyngier <maz@kernel.org>
Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
In-reply-to: <20200803113841.pqqpo4hqfwru3upq@skbuf>
Date:   Mon, 03 Aug 2020 12:48:35 +0100
Message-ID: <jhjime0hrvw.mognet@arm.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 03/08/20 12:38, Vladimir Oltean wrote:
> On Mon, Aug 03, 2020 at 10:51:32AM +0100, Robin Murphy wrote:
>> 
>> Having glanced across another thread that mentions IRQ accounting
>> recently[1], I wonder if the underlying bug here might have something do to
>> with the stuff that Marc's trying to clean up.
>> 
>> Robin.
>> 
>> [1] https://lore.kernel.org/linux-arm-kernel/20200624195811.435857-16-maz@kernel.org/
>
> Thanks Robin. I've applied Marc's "[PATCH v2 00/17] arm/arm64: Turning
> IPIs into normal interrupts" series and the LS1028A I'm debugging hangs
> in absolutely the same way.
>

I'm not too surprised by that, wrt accounting this mostly changes where the
stores go to and barely shuffles when they happen (slightly earlier on the
IPI handling path).

FWIW I've had 'stress-ng --hrtimers 1' running on my Juno and eMAG for ~15
minutes and haven't had a splat yet. 

> -Vladimir