Messages in this thread | | | Date | Mon, 14 Nov 2022 19:59:06 +0100 | Subject | Re: [GIT PULL] arm64 updates for 6.1-rc1 #forregzbot | From | Thorsten Leemhuis <> |
| |
[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.
| |