Re: [GIT PULL] arm64 updates for 6.1-rc1

From: Amit Pundir <amit.pundir@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	 Bjorn Andersson <andersson@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Subject: Re: [GIT PULL] arm64 updates for 6.1-rc1
Date: Tue, 25 Oct 2022 18:08:24 +0530	[thread overview]
Message-ID: <CAMi1Hd3Y9AibeVnh9_KYJ2EXar7bBSypKm4Tixj47htM7ZOURw@mail.gmail.com> (raw)
In-Reply-To: <Y0aq8y5mEZi14lJ/@arm.com>

On Wed, 12 Oct 2022 at 17:24, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Hi Amit,
>
> On Sat, Oct 08, 2022 at 08:28:26PM +0530, Amit Pundir wrote:
> > On Wed, 5 Oct 2022 at 20:11, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > Will Deacon (2):
> > >       arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()
> >
> > Hi Will,
> >
> > This patch broke AOSP on Dragonboard 845c (SDM845). I don't see any
> > relevant crash in the attached log and device silently reboots into
> > USB crash dump mode. The crash is fairly reproducible on db845c. I
> > could trigger it twice in 5 reboots and it always crash at the same
> > point during the boot process. Reverting this patch fixes the crash.
> >
> > I'm happy to test run any debug patche(s), that would help narrow
> > down this breakage.
>
> Cc'ing Robin, maybe he has a better idea (that's commit c44094eee32f).
> Architecturally the change shouldn't make any difference since the cache
> lines can be brought in via the linear mapping at any point. It's just
> less likely to hit a real bug (software or hardware). It's also possible
> that arch_dma_prep_coherent() is used outside the DMA API (if you have
> out of tree drivers).
>
> Leaving the original log in place for Robin. A question I have, with a
> successful boot, what's normally after the bpfloader lines are printed?
> We should try to pinpoint which device/driver causes this. It looks like
> it's well into user-space at that point (graphics about to start?)

Further narrowed down the breakage to the userspace daemon rmtfs
https://github.com/andersson/rmtfs. Is there anything specific in the
userspace code that I should be paying attention to?

console:/ #
console:/ # start rmtfs
[   56.425631][    T1] init: starting service 'rmtfs'...
[   56.455541][    T1] init: Control message: Processed ctl.start for
'rmtfs' from pid: 1819 (start rmtfs)
[   56.487524][  T344] type=1400 audit(1666698550.979:267): avc:
denied { read } for comm="rmtfs" name="modalias" dev="sysfs" ino=6325
scontext=u:r:rmtfs:s0 tcontext=u:object_r:sysfs:s0 tclass=file
permissive=1
[   56.487662][ T1821] remoteproc remoteproc0: powering up 4080000.remoteproc
[   56.506365][  T344] type=1400 audit(1666698550.979:268): avc:
denied { open } for comm="rmtfs"
path="/sys/devices/platform/remoteproc-cdsp/modalias" dev="sysfs"
ino=6325 scontext=u:r:rmtfs:s0 tcontext=u:object_r:sysfs:s0
tclass=file permissive=1
[   56.515137][ T1821] remoteproc remoteproc0: Booting fw image
qcom/sdm845/mba.mbn, size 242400
[   56.535020][  T344] type=1400 audit(1666698550.979:269): avc:
denied { read } for comm="rmtfs" name="modalias" dev="sysfs" ino=7200
scontext=u:r:rmtfs:s0 tcontext=u:object_r:sysfs_remoteproc:s0
tclass=file permissive=1
[   56.621541][ T1821] qcom-q6v5-mss 4080000.remoteproc: MBA booted
without debug policy, loading mpss

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel