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

Thorsten Leemhuis
2022-11-14T18:59:37Z

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker.

On 08.11.22 18:28, Amit Pundir wrote:
> On Tue, 25 Oct 2022 at 18:08, Amit Pundir <amit.pundir@linaro.org> wrote:
>>
>> 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?

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced c44094eee32f
#regzbot title arm64: crash on the Qualcomm SM8250
#regzbot monitor
https://lore.kernel.org/all/20221114110329.68413-1-manivannan.sadhasivam@linaro.org/

#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.