On Mon, Nov 21, 2022 at 08:50:11PM +0100, David Hildenbrand wrote: > On 21.11.22 20:03, Luis Chamberlain wrote: > > 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? > > Yes, that's the one I tried without luck. OK thanks. I'm just trying to sort out the regression first before we go out and fix another issue. We will chase that issue down though and I hav some other ideas to help with this further too. Luis
