On Mon, Nov 21, 2022 at 05:00:49PM +0100, Petr Pavlu wrote: > On 11/16/22 17:03, Prarit Bhargava wrote: > > On 11/15/22 14:29, Luis Chamberlain wrote: > >> On Mon, Nov 14, 2022 at 04:45:05PM +0100, David Hildenbrand wrote: > >>> Note that I don't think the issue I raised is due to 6e6de3dee51a. > >>> I don't have the machine at hand right now. But, again, I doubt this will > >>> fix it. > >> > >> There are *more* modules processed after that commit. That's all. So > >> testing would be appreciated. > >> > > > > Can anyone tell us if > > > > https://lore.kernel.org/linux-pm/20221102195957.82871-1-stuart.w.hayes@xxxxxxxxx/ > > > > resolves the module loading delay problem? > > This patch unfortunately makes no difference on my test system. In my case, > the kernel has already intel_pstate loaded when udev starts inserting a burst > of acpi_cpufreq modules. It then causes the init function acpi_cpufreq_init() > to immediately return once the check cpufreq_get_current_driver() fails. The > code modified by the patch is not reached at all. To be clear I don't care about the patch mentioned in the above URL, I care about this: https://lkml.kernel.org/r/d0bc50e3-0e42-311b-20ed-7538bb918c5b@xxxxxxxx David was this the on you tested too? Prarit, so you're left to please test, the hope would be that at the very least it still fixes your issue. Petr, you had mentioned in the commit log for your second patch in this thread that your change fixes a regression. What I asked for was for a patch that fixes that regression alone first so we can send to stable. So what issue is that alternative patch fixing? Luis
