Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759433Ab3EWPGK (ORCPT ); Thu, 23 May 2013 11:06:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33240 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758797Ab3EWPGI (ORCPT ); Thu, 23 May 2013 11:06:08 -0400 Date: Thu, 23 May 2013 17:06:27 +0200 Message-ID: From: Takashi Iwai To: Dave Jones Cc: Ming Lei , "H. Peter Anvin" , Linux Kernel , x86@kernel.org, fenghua.yu@intel.com Subject: Re: microcode loading got really slow. In-Reply-To: <20130523144800.GB16419@redhat.com> References: <20130523144800.GB16419@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2533 Lines: 64 At Thu, 23 May 2013 10:48:00 -0400, Dave Jones wrote: > > On Thu, May 23, 2013 at 04:36:20PM +0200, Takashi Iwai wrote: > > > > >> Also udev supports user-defined rules to load firmware, which > > > >> means some drivers may not put their firmware in the default > > > >> path of distribution's firmware. > > > > > > > > It's why I suggested to put a warning in that path as the first step. > > > > So we can see whether there is any actual user. > > > > > > If you plan to do it, it'd better to add default firmware path of some > > > distributions into firmware_class.c first, otherwise it may cause > > > unnecessary noise for this distribution. > > > > > > But if more default search paths are added, it might cause mistaken > > > firmwares found under incorrect path, for example, android's > > > default path is "/etc/firmware" and "/vendor/firmware"(maybe different > > > for different versions). > > > > > > Also, putting default search paths into kernel isn't good, which was > > > introduced unwillingly for well-known reason. > > > > Maybe we can create a new Kconfig to specify non-standard firmware > > path? > > You keep mentioning non-standard paths for firmware, but in this case, > I don't think Fedora is doing anything unusual. We have microcode firmware > in /lib/firmware/intel-ucode/ just like (afaik) everyone else. > > What *is* happening, I think is that the CPU is new enough that there's no > newer firmware file available for it. > > thoughts? Yes, in your case, everything is fine in the kernel itself. And no microcode update is needed for new CPU, thus no firmware. The problem is that the f/w loader tries to call udev and udev gets stuck when invoked from module init. This doesn't hit most drivers because usually the firmware is mandatory and it must exist. Thus the direct f/w loading always works for them. If it hits, it's only the error case. But, for the microcode loader, it's normal that the firmware doesn't exist, like your case. Unfortunately, this falls back to user helper mode, and now you're seeing the problem. So, the option would be to fix udev, let it behaving like before. The second option would be to change ("fix") the kernel behavior, but the question is which way. Takashi > Dave > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/