Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <FA654A0D-29B7-4B6B-B613-73598A92ADA8@goldelico.com>
 <YmkBAsa+fKlp/GcV@atomide.com> <CAK8P3a3N9WBWC_ECB0pSRHUCT4iz=tdT+Dt9Cyd5Wh3qEaVqqA@mail.gmail.com>
 <4CE23DC3-B3E5-45C1-91F3-B88E5444AE7C@goldelico.com> <CAK8P3a3EFfF0gr5kFkboRfJifrY-D+NgHFekBfSePWuY2c8PMA@mail.gmail.com>
 <11504A17-6B50-4D6C-A9E1-CA943C157C93@goldelico.com>
In-Reply-To: <11504A17-6B50-4D6C-A9E1-CA943C157C93@goldelico.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 30 Apr 2022 20:48:11 +0200
Message-ID: <CAK8P3a2RN77ajZD4xRhKsqozPizneLcLYhm0rTE6qX25-4cJsw@mail.gmail.com>
Subject: Re: kernel panic with v5.18-rc1 on OpenPandora (only)
To:     "H. Nikolaus Schaller" <hns@goldelico.com>
Cc:     Arnd Bergmann <arnd@arndb.de>, Tony Lindgren <tony@atomide.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@openphoenux.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-OMAP <linux-omap@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Ard Biesheuvel <ardb@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Apr 30, 2022 at 7:18 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> > Am 30.04.2022 um 17:36 schrieb Arnd Bergmann <arnd@arndb.de>:
> >
> >
> > I suppose this could be anywhere then. The backtrace seems to point
> > to re-enabling interupts in do_work_pending, so something probably
> > accessed DMA memory asynchronously.
>
> Yes. I now (or still) sometimes see the same omap l3 irq issue when plugging in/out the USB/OTG
> cable. Not with a kernel panic, but in the same driver omap_l3_smx.c.
> This happens even if the wl1251 driver is removed.

Is this also a regression, or did it happen before the vmap-stack
change? If this only
appeared now, then this points to another bug somewhere that you
should find using
CONFIG_DMA_API_DEBUG.

I think what is going on here is that your platform is able to detect
the broken DMA
because of the l3 interrupt handler telling the kernel about it, when
on other platforms
we would see either silent data corruption or a DMA that never reaches
its target.

       Arnd