Re: amd_sfh driver causes kernel oops during boot

[Malte Starostik <malte@starostik.de>]

Am Dienstag, 6. Juni 2023, 08:56:16 CEST schrieb Linux regression tracking 
(Thorsten Leemhuis):
> On 06.06.23 04:36, Bagas Sanjaya wrote:
> > On Mon, Jun 05, 2023 at 01:24:25PM +0200, Malte Starostik wrote:
> >> chiming in here as I'm experiencing what looks like the exact same issue,
> >> also on a Lenovo Z13 notebook, also on Arch:

> >> bisect result:
> >> 904e28c6de083fa4834cdbd0026470ddc30676fc is the first bad commit
> >> commit 904e28c6de083fa4834cdbd0026470ddc30676fc
> >> Merge: a738688177dc 2f7f4efb9411
> >> Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >> Date:   Wed Feb 22 10:44:31 2023 +0100
> >> 
> >>     Merge branch 'for-6.3/hid-bpf' into for-linus
> > 
> > Hmm, seems like bad bisect (bisected to HID-BPF which IMO isn't related
> > to amd_sfh). Can you repeat the bisection?

I'm digging further. That merge is what git bisect ended at, but admittedly my 
git skills and especially with a large codebase aren't too advanced.
While at 904e28c6de083fa4834cdbd0026470ddc30676fc, git show only shows the diff 
for tools/testing/selftests/Makefile which can't really be the culprit. 
However, git diff @~..@ has changes in drivers/hid/amd-sfh-hid/Kconfig (seems 
innocuous, too), but also some changes to drivers/hid/hid-core.c. Nothing 
obvious either, but at least it's not too far from the trace.

> Well, amd_sfh afaics apparently interacts with HID (see trace earlier in
> the thread), so it's not that far away. But it's a merge commit, which
> is possible, but doesn't happen every day. So a recheck might really be
> a good idea.

I will recheck some more, the Oops only happens with roughly 30 % chance 
during boot. When it doesn't, there seem to be no other issues until the next 
boot either. I made sure to reboot a few times after each bisect step, will 
look deeper into the area.

> > Anyway, tl;dr:
> >> A: http://en.wikipedia.org/wiki/Top_post
> >> Q: Were do I find info about this thing called top-posting?
> > 
> > [...]
> 
> BTW, I'm not sure if this really is helpful. Teaching this to upcoming
> kernel developers is definitely worth it, but I wonder if pushing this
> on all reporters might do more harm than good. I also wonder if asking
> them a bit more kindly might be wiser (e.g. instead of "Anyway, tl;dr:"
> something like "BTW, please do not top-post:" or something like that maybe).

Thanks, and I agree in general. However, my case was in fact even worse :-) 
I'm totally aware of the badness of top-posting. It happened because I had a 
draft of the reply. Set In-Reply-To from the link in the wev archive and 
pasted the previous message from there. Couple days later, I just pasted the 
result on top and disregarded the existing text.

BR Malte