On Tue, 05 Nov 2024 16:57:07 +0000, Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Fri, Nov 01, 2024 at 02:43:57PM +0000, Marc Zyngier wrote: > > On Fri, 01 Nov 2024 14:19:54 +0000, > > Johan Hovold <johan@xxxxxxxxxx> wrote: > > > > The side-effects and these remaining warnings are addressed by this > > > series: > > > > > > https://lore.kernel.org/all/20241030125512.2884761-1-quic_sibis@xxxxxxxxxxx/ > > > > > > but I think we should try to make the warnings a bit more informative > > > (and less scary) by printing something along the lines of: > > > > > > arm-scmi arm-scmi.0.auto: [Firmware Bug]: Ignoring duplicate OPP 3417600 for NCC > > > > > > instead. > > > > Indeed. Seeing [Firmware Bug] has a comforting feeling of > > familiarity... :) > > > > I wonder whether the same sort of reset happen on more "commercial" > > systems (such as some of the laptops). You expect that people look at > > the cpufreq stuff closely, and don't see things exploding like we are. > > I finally got around to getting my Lenovo ThinkPad T14s to boot (it > refuses to start the kernel when using GRUB, and it's not due to the > known 64 GB memory issue as it only has 32 GB) <cry> I know the feeling. My devkit can't use GRUB either, so I added a hook to the GRUB config to generate EFI scripts that directly execute the kernel with initrd, dtb, and command line. This is probably the worse firmware I've seen in a very long while. </cry> > and can confirm that it > hard resets when accessing the cpufreq sysfs attributes as well. Right. So this also happens on non-abandonware machines. > On the bright side, at least I don't see any warnings due to duplicate > OPPs on this machine (x1e78100, latest UEFI fw). One bug fixed... M. -- Without deviation from the norm, progress is not possible.
