Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759795Ab3EWP1O (ORCPT ); Thu, 23 May 2013 11:27:14 -0400 Received: from mail-ie0-f181.google.com ([209.85.223.181]:42905 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759778Ab3EWP1J (ORCPT ); Thu, 23 May 2013 11:27:09 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130523144800.GB16419@redhat.com> Date: Thu, 23 May 2013 23:27:08 +0800 Message-ID: Subject: Re: microcode loading got really slow. From: Ming Lei To: Takashi Iwai Cc: Dave Jones , "H. Peter Anvin" , Linux Kernel , x86@kernel.org, fenghua.yu@intel.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3112 Lines: 74 On Thu, May 23, 2013 at 11:06 PM, Takashi Iwai wrote: > 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. Can the driver decide if the CPU need microcode? Or there will be the microcode for the CPU in future? > > 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. The problem is that if driver call request_firmware(), it means it need the firmware and it know there should be one. So maybe the driver shouldn't call request_firmware() if it can figure out that case. > 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. Sounds like the microcode driver depends on userspace or filesystem to decide if there is one microcode available for me, is the way correct? Thanks, -- Ming Lei -- 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/